Financial news for AI agents: search, trending, insider, earnings reads, macro, scored 1-10.
Scored across 19 tools
Most tools target a clearly distinct resource (article, earnings, calendar, alerts, watchlist, tickers), and the long descriptions explicitly contrast overlapping use cases. The main ambiguity is among the several news-feed variants (actionable_now, trending, macro, news_search, ticker_news, insider_news), but each has a distinct time window, filter, and ranking purpose. Insider_news is openly described as equivalent to a news_search category, adding intentional redundancy without making the boundaries impossible to discern.
All alphai_ tools share a consistent snake_case alphai_ prefix and mostly use clear resource-oriented names like alerts_list, news_search, ticker_news, and watchlist_brief. The two connector tools `fetch` and `search` lack the prefix, and a few names are bare nouns (article, calendar, macro, radar), which are minor deviations. Overall the naming pattern is predictable and readable.
At 19 tools, the server is on the heavy side and includes several near-duplicate news-feed endpoints that could have been consolidated with parameters. The breadth is defensible for a full financial news and intelligence API, but it feels borderline and risks overwhelming an agent with redundant choices.
The tool set covers the core domain well: news search and feeds, article lookup, earnings reads, macro calendar, insider screens, alert subscription CRUD, watchlist briefing, and ticker metadata. Minor gaps exist—watchlist management is deferred to the website and there is no dedicated price/quote tool—but these fall outside the stated news-intelligence scope. The primary workflows have no dead ends.
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. Market-wide macro releases (an FOMC decision, a CPI/jobs print) qualify and carry no tickers. An empty list on quiet 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), and each collapsed item reports story_id (the story root's uid — the same key alphai_trending and the search tools report for that story), sources_count and sources. Most stories run at a single outlet, so sources_count is usually 1; a value above 1 is the signal, not the number itself. 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 20 Free/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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive, but the description adds substantial behavioral context: the time window is based on publication time rather than event date, dedupe collapses syndicated reprints, results are ordered novelty-first, and each item carries full AI analysis inline. It also discloses the meaning of sources_count and the expected empty-list behavior, going far beyond the structured 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 content is dense and front-loaded, with every sentence earning its place by addressing a real decision or edge case. However, it is a single long paragraph rather than structured sections, which reduces scannability for an agent. It earns a 4 rather than a 5 because the length could be tightened or structured 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?
Given the tool's complexity, the description is remarkably complete: it covers default behavior, parameter changes, sibling routing, temporal semantics, dedupe behavior, sourcing signals, empty-result interpretation, macro releases, and inline analysis payloads. The output schema exists, so the description does not need to explain return shape, and nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful parameter semantics: it explains the min_actionability threshold difference between 'high' and 'medium', clarifies that min_novelty (not the window) filters post-event recaps, and ties dedupe to story-level collapse. The limit parameter is not discussed, but its schema description is self-explanatory.
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 this is a feed of breaking, decision-grade news from the last few hours, filtered primarily by actionability. It distinguishes itself from alphai_trending and alphai_ticker_news by explaining the strict high-actionability default and how medium-actionability stories are excluded. The verb and resource are specific enough that an agent knows exactly what this tool returns.
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 when-to-use guidance: use this for time-sensitive, high-actionability developments, and lower min_actionability to 'medium' for stories that shape positions over days/weeks. It also names alternatives (alphai_trending, alphai_ticker_news) for the broader tape, and explains that empty results on quiet nights/weekends are expected rather than errors. This is model routing guidance, not just a definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the caller's active ticker news-alert subscriptions, including per-subscription filters (category whitelist, minimum relevance score, delivery mode).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tier | Yes | |
| limit | Yes | |
| alerts | No | |
| current | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations by specifying that only the caller's active subscriptions are returned and that per-subscription filters are included, which clarifies the scope and content of the response.
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, tight sentence that front-loads the primary action and resource, then adds the relevant detail about included filters. There is no redundancy with the title or schema, and every word contributes meaning.
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 zero-parameter, read-only list tool with an output schema present, the description is complete: it states whose subscriptions are returned, that they are active, and what fields are included. The output schema covers return-value structure, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the description has no parameter-level responsibility. Per the rubric baseline for 0-param tools, a score of 4 is appropriate; the description does not need to add parameter meaning that does not exist.
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 states a specific verb ('List'), a clear resource ('the caller's active ticker news-alert subscriptions'), and the kind of data included ('filters: category whitelist, minimum relevance score, delivery mode'). It clearly differentiates this from sibling tools like alphai_alerts_subscribe and alphai_alerts_unsubscribe by focusing on read-only listing.
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 intended use is implied strongly by the verb and noun phrase: use this when the agent needs to see the caller's existing alert subscriptions. However, there is no explicit guidance about when not to use it or how it compares to related alert-management tools, so the agent must infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 7. Note the threshold applies to email and telegram delivery; a Pro webhook receives the full matched stream and filters on its own. Raises tier_not_paid / unknown_ticker / limit_reached. Crypto alerts use the -USD ticker (BTC-USD); subscribing to a collider string like BTC binds the stock/ETF that owns it and the response's note field says so.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker to subscribe to (active symbol). | |
| category_filter | No | Categories that trigger alerts. | |
| min_relevance_score | No | Min relevance to alert on. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| ticker | Yes | |
| is_active | Yes | |
| created_at | Yes | |
| delivery_mode | Yes | |
| category_filter | No | |
| min_relevance_score | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses critical behaviors: partial updates preserve omitted fields on existing subscriptions, new subscriptions default min_relevance_score to 7, thresholds apply to email/telegram but not Pro webhooks, exact error conditions are listed, and crypto tickers require the -USD suffix to avoid colliders. This is rich behavioral context that annotations alone could never 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 dense but every sentence earns its place: operation type, parameter behavior, update semantics, delivery-channel nuance, error list, and crypto edge case. It is front-loaded with the core purpose and then layers necessary caveats without 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?
For a subscription tool with partial-update semantics and special cases, the description covers all the non-obvious behavior an agent needs: default values, delivery-channel differences, error conditions, and the crypto ticker format. The output schema exists, so the description needn't explain the return structure, and it even references the response's note field for the collider case.
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?
Even though schema description coverage is 100%, the description adds significant meaning: it gives an example category_filter value, explains that min_relevance_score raises the threshold, clarifies the default value for new subscriptions, and describes the ticker collider issue (BTC vs BTC-USD). This goes well beyond the schema's short field 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 opens with 'WRITE operation (creates/updates a saved subscription in the caller's account)' and then states 'Subscribe the caller to ticker news alerts.' This gives a specific verb, resource, and side-effect, and clearly separates this from the sibling read tool alphai_alerts_list and deletion tool 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?
Clear context is provided: the tool is the write path for creating or updating a saved subscription, and the partial-update behavior tells an agent exactly how to modify an existing subscription. However, it never explicitly names alphai_alerts_list or alphai_alerts_unsubscribe as alternatives, so an agent must infer when to read or remove instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=true, and the description adds valuable specifics: it is a soft-disable scoped to the caller's account, returns {removed: false} when already inactive, and raises unknown_ticker for unrecognized symbols. This goes well beyond the structured 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 and front-loaded with the operation type and effect. There is slight redundancy between 'deactivates a saved subscription' and 'soft-disable the caller's news-alert subscription,' but every sentence otherwise contributes behavioral or error 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?
For a one-parameter tool with an output schema, the description is complete: it covers the operation, account scoping, idempotency behavior, a concrete return case, and the main error condition. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the ticker parameter is already documented. The description adds extra meaning by clarifying that an unrecognized symbol will raise unknown_ticker, so the agent knows the value must correspond to a recognized ticker, not merely match the pattern.
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 a specific verb and resource: it deactivates/soft-disables the caller's news-alert subscription for a given ticker. This distinguishes it from siblings like alphai_alerts_subscribe and alphai_alerts_list, even without naming them.
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 makes the use case clear: the caller wants to deactivate an existing ticker alert subscription. It does not explicitly list alternatives or exclusion conditions, but the operation type and idempotent behavior give sufficient context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | The article uid from any feed response. |
| Name | Required | Description |
|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
The forward half of the macro loop: the official US economic calendar — scheduled FOMC decisions (with SEP and press-conference markers) and minutes, CPI, PPI, the jobs report, GDP estimates, PCE, retail sales, weekly jobless claims and JOLTS, from the agencies' own schedules. Ask it 'what macro releases are coming this week', then read alphai_macro for what a release meant once it is out. Each occurrence carries a stable uid that survives reschedules, plus phase: 'elapsed' means the scheduled moment passed (NOT that the agency published — check schedule_status; schedule_basis='inferred' marks dates derived from the release cadence rather than printed by the agency). Elapsed SCHEDULED occurrences include coverage: the top feed stories about that release (uid + relevance score) — fetch depth per story via alphai_article; cancelled/postponed rows return coverage=null. days_back counts from today's UTC midnight, so the default 0 still includes today's already-released prints with their coverage. This tool is US MACRO only: for a company's next earnings date, read next_report_date on alphai_tickers. Informational and AI-generated — not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| days_back | No | Days back from today's UTC midnight; default 0 still includes today's releases. Also capped by your archive depth. | |
| days_ahead | No | Days forward from now; default 7. | |
| event_keys | No | Narrow to specific series; default all. | |
| importance | No | Filter by importance tier. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent annotations by explaining subtle behaviors: elapsed means the scheduled moment passed, not that the agency published; schedule_basis='inferred' marks cadence-derived dates; cancelled/postponed rows return coverage=null; elapsed SCHEDULED occurrences include coverage with uid and relevance scores. It also clarifies days_back semantics around UTC midnight. This is rich, non-obvious behavioral disclosure that an agent needs to interpret results correctly.
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 long but dense and mostly front-loaded: the core purpose appears in the first sentence, with sibling routing early. The later caveats about phase, schedule_basis, coverage, and cancellation behavior are necessary for correct interpretation of results. It could be tightened slightly, but the length is justified by the complexity of the calendar semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers everything an agent needs: what data is included, how to filter, how to interpret elapsed/inferred/cancelled states, what coverage contains, and where to go for related data. The references to alphai_macro, alphai_article, and alphai_tickers close the remaining contextual gaps. Nothing critical is missing for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the schema already describes days_back, days_ahead, event_keys, and importance. The description adds meaningful semantic nuance beyond the schema: days_back counts from today's UTC midnight so default 0 still includes today's already-released prints with coverage, and event occurrences carry stable uids and phase semantics. This elevates it above the baseline.
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 names a specific verb+resource: it provides the official US economic calendar with scheduled macro releases. It lists concrete event types (FOMC, CPI, PPI, jobs report, GDP, PCE, etc.) and explicitly distinguishes itself from siblings: alphai_macro for post-release interpretation and alphai_tickers for earnings dates. This makes the tool's scope 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 usage direction: ask it about upcoming macro releases, then use alphai_macro once a release is out. It also states an exclusion boundary: 'This tool is US MACRO only' and redirects earnings-date lookups to alphai_tickers.next_report_date. It even routes story depth retrieval to alphai_article, so the agent knows exactly when to pick this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AlphAI's own structured read of a company's earnings reports, newest first, plus its next confirmed report date. Each read is produced from the company's OWN SEC filing — an 8-K item 2.02 for US filers, a 6-K earnings release for foreign private issuers — within minutes of it reaching EDGAR, and every figure in it was checked against the filing text before publication, so it is the arbiter when press coverage of the same quarter disagrees. Carries reported metrics with year-over-year and sequential comparisons, segments, guidance, drivers, concerns and management quotes; each key_metrics row also carries numeric, unit and scale next to the printed value (scale is null when the filing does not say). This is the tool to reach for after alphai_tickers gives you a next_report_date: the feed tools return articles ABOUT a quarter, this returns the filing's own numbers. Share classes bridge, and each row reports the class the filing was made under. Depth is shallow by construction — AlphAI's reads begin with filings from late July 2026 and reports are quarterly — so most tickers carry one or two reads and an empty list is a normal answer, not an error. Informational and AI-generated — not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol, e.g. 'NVDA'. |
| Name | Required | Description |
|---|---|---|
| ticker | Yes | |
| reports | No | |
| unknown_ticker | No | |
| next_report_date | No |
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 valuable behavioral context beyond those: the source filings (8-K item 2.02 / 6-K), the verification against filing text, the arbitrating role, shallow depth by construction, coverage starting late July 2026, and the scale-null edge case. No contradiction with annotations; the informational disclaimer aligns with the read-only intent.
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 longer than average, but every sentence earns its place by adding behavioral or usage-critical context. It is front-loaded with the core purpose and then layers source, content, routing, edge cases, and disclaimer. It could be tightened slightly by trimming the detailed enumeration of metrics, but the overall structure is purposeful and not padded.
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 that an output schema exists (so return values do not need to be spelled out) and the tool takes only one parameter, the description is complete for safe and correct invocation. It explains data availability ('most tickers carry one or two reads'), expected ordering ('newest first'), the meaning of empty lists, and the tool's relationship to alphai_tickers. Nothing needed for an agent to decide when and how to call it is missing.
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%: the single 'ticker' parameter is already described with a pattern, maxLength, and example 'NVDA'. The description does not add new parameter-level semantics beyond what the schema provides. Since schema coverage is high, the baseline of 3 applies; the tool description focuses on output behavior rather than input details, which is acceptable.
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 states a specific verb and resource: 'AlphAI's own structured read of a company's earnings reports, newest first, plus its next confirmed report date.' It clearly differentiates from sibling feed tools by stating 'the feed tools return articles ABOUT a quarter, this returns the filing's own numbers.' The role of being the arbiter for contested figures further nails down what this tool uniquely provides.
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 when-to-use guidance: 'This is the tool to reach for after alphai_tickers gives you a next_report_date.' It names the alternative category (feed tools) and explains why this tool is preferable when filing-level numbers are needed. It also sets expectations that empty results are normal, preventing false negative interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find issuers where several different insiders bought on the open market in one run of purchases (SEC Form 4, purchase dates chained while at most 10 days apart, an episode capped at 30 days). Every purchase is examined before a buyer counts: an IPO or PIPE allocation — by its price shape or by the filing's own footnote saying the shares came from the issuer, an offering or a negotiated block (buyer reason: placement, offering, private) — ESPP / DRIP / director-plan lots, units and note exchanges without a price, and the same transaction reported through two owners are labeled per buyer (role: independent, plan_like, unpriced, duplicate_of) and hidden from the default open_market list; ask pattern=plan_or_offering, holders_only or all to see them. buyers counts independent buyers, buyers_total everyone who bought. days is measured on known_at, the moment the episode's latest filing reached EDGAR, so 'what became known this month' is one call; a Free account reaches 30 days, Basic and Pro 90. Sort recent (default, newest known first), buyers or value; follow next_cursor with the same sort. Each result links every filing (accession number, EDGAR URL) and the news uids to open with alphai_article. Descriptive screen, not point-in-time and not a return forecast; coverage starts at meta.coverage_since (the table begins in August 2025).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback in days over known_at (latest filing); default 30. | |
| sort | No | recent = newest known first. | recent |
| limit | No | Rows per page, default 10; above 20 needs Pro. | |
| cursor | No | Opaque next_cursor, unchanged. | |
| symbol | No | One ticker; former names and share-class siblings match too. Empty for the whole market. | |
| min_usd | No | Drop episodes whose known total is below this many dollars. | |
| pattern | No | Which verdicts to return; open_market by default. | open_market |
| min_buyers | No | Minimum independent buyers for open_market rows (everyone who bought for plan rows). |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| results | No | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses substantial behavior: how purchases are classified and hidden by default, that buyers counts only independent buyers, that days is measured on known_at, account-tier limits on lookback, and that the table starts in August 2025. This is exactly the kind of non-obvious behavior an agent needs to interpret results correctly.
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 dense and front-loaded with the core purpose, and every sentence contributes meaningful detail. However, it is delivered as one long paragraph with many embedded clauses; breaking it into a few shorter blocks or bullets would make it easier to parse 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?
Given the tool's complexity, eight parameters, and existing output schema, the description is remarkably complete. It covers the classification rules, default behavior, pagination with sort consistency, account limitations, links to filings and news uids, and the coverage start date. There are no obvious gaps an agent would need to fill by trial and error.
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?
Although the schema already has 100% parameter description coverage, the tool description adds deeper meaning: it explains what each pattern value returns, clarifies that min_buyers counts independent buyers for open_market but everyone for plan rows, and discusses account-tier differences for days and limit. This goes well beyond the baseline expected when schema descriptions are already strong.
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 opens with a precise verb and resource: 'Find issuers where several different insiders bought on the open market in one run of purchases.' It further specifies the SEC Form 4 basis, date-chaining rules, and episode cap, making it clearly distinct from sibling tools like alphai_insider_news or alphai_tickers.
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 strong contextual cues: 'what became known this month is one call', and explicitly states the tool is 'Descriptive screen, not point-in-time and not a return forecast', which sets expectations for appropriate use. It does not name alternative sibling tools for comparison, so it falls short of fully explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insider-transaction news: SEC Form 4 insider trades (company officers, directors and 10% owners buying or selling their own stock). Optionally filter by ticker, date range, and whether the trade ran under a pre-scheduled Rule 10b5-1 plan (is_10b5_1=false hides planned sales, leaving discretionary trades). Cursor-paginated; same shape (incl. the full inline AI analysis) as alphai_news_search, and the same sort='ingested' delta polling for watching new filings arrive. Roughly equivalent to alphai_news_search(category='insider'), exposed as a dedicated tool. Sets unknown_ticker=true only for an unrecognized ticker filter; a delisted symbol serves its history with delisted=true and renamed_to set when the company continues under a new ticker. When the ticker is a crypto collider (BTC = the Grayscale ETF, not the coin), ticker_note names the -USD coin ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | published (default): newest first. ingested: delta polling — only Form 4 events added since your cursor, ascending; next_cursor is always returned (empty items = caught up, keep the cursor and poll later). Prefer this for watching insider activity: a filing arrives days after its transaction date, so it can land below the newest page of a publish-ordered feed. A cursor only works with the sort mode that issued it. | |
| 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); a bare date covers that whole day. Bounds when the filing reached the feed, not the insider's transaction_date. | |
| from_date | No | On/after this ISO time (UTC if naive); a bare date means that day's midnight. | |
| is_10b5_1 | No | Rule 10b5-1 filter, on the same field each item's insider block reports. Omit for every event; false = discretionary trades only (a 10b5-1 ladder was scheduled months earlier, so it carries no timing decision); true = plan events only. Event-level: a filing mixing plan and discretionary tranches counts as a plan event. | |
| page_size | No | Items/page; capped at 20 Free/Basic, 50 Pro. | |
| min_relevance | No | Minimum AI relevance score, 1-10. |
| Name | Required | Description |
|---|---|---|
| count | No | |
| items | No | |
| delisted | No | |
| renamed_to | No | |
| next_cursor | No | |
| ticker_note | No | |
| unknown_ticker | No | |
| query_interpretation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: cursor-paginated shape, same inline AI analysis as alphai_news_search, sort='ingested' delta polling semantics, unknown_ticker=true only for unrecognized tickers, delisted symbols serving history with delisted=true/renamed_to, and crypto collider handling. These details are not present in annotations and materially help an agent anticipate 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?
Every sentence earns its place. The description front-loads the core purpose, then adds filters, pagination, equivalence to sibling, and edge cases in a logical order. It is dense but not redundant, and the length is justified by the tool's complexity (9 parameters, multiple edge cases).
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?
The description is complete for a read-only, idempotent API tool. It covers pagination, sort behavior, ticker edge cases (delisted, crypto collider), and references the output shape. Combined with the provided output schema and detailed parameter descriptions, an agent has everything needed to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a detailed description. The tool description mostly rephrases schema content (filter by ticker, date range, is_10b5_1) and does not add new parameter-specific semantics. It does provide output-context details like unknown_ticker and delisted flags, but those are behavioral rather than parameter semantics, so the baseline 3 applies.
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?
States the specific resource and verb: "Insider-transaction news: SEC Form 4 insider trades (company officers, directors and 10% owners buying or selling their own stock)." It also differentiates from alphai_news_search by noting it is "Roughly equivalent to alphai_news_search(category='insider'), exposed as a dedicated tool," making the purpose and sibling relationship explicit.
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: identifies itself as a dedicated equivalent to alphai_news_search(category='insider'), and gives specific advice for watching activity ("Prefer this for watching insider activity" for sort='ingested'). However, it does not explicitly state when not to use this tool versus other siblings like alphai_ticker_news or alphai_insider_clusters, so it stops short of a full when/when-not matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The market-wide macro tape from the last N hours: central-bank decisions and statements (Fed/FOMC), inflation and jobs prints, commodities, geopolitics — one call, novelty-first, so on a release day the release itself leads and the commentary follows. Use this for 'what did the Fed say', 'any macro news today', 'what's moving the whole market'. Macro rows are market-wide events and mostly carry NO tickers — that is by design; each item still carries the full AI analysis inline. Narrow with categories, or raise min_relevance to 7 to keep roughly the release-day events and drop the commentary. Syndicated reprints are collapsed by story (dedupe=false to keep all), and each collapsed item reports story_id (the story root's uid — the same key alphai_trending and the search tools report), sources_count and sources; sources_count is usually 1, a value above 1 is the signal. For what is COMING — the scheduled release calendar — use alphai_calendar. Informational and AI-generated — not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | Look-back window in hours; default 24. | |
| limit | No | Items; capped at 20 Free/Basic, 50 Pro. | |
| dedupe | No | Collapse syndicated reprints by story (default true). | |
| categories | No | Subset of the macro categories; default all three. | |
| min_relevance | No | Min AI relevance 1-10; default 4. 7+ keeps release-day events. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds substantial context beyond that: the novelty-first ordering, collapse of syndicated reprints via dedupe, the significance of sources_count>1 as a signal, that rows mostly carry no tickers by design, and each item includes full AI analysis inline. It also discloses the 'not investment advice' disclaimer. This goes well beyond the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph of about 150 words. Every sentence carries functional meaning—scope, use cases, dedupe behavior, source signal, and pointer to calendar. It is front-loaded with the core purpose and flows logically. While it is lengthy, the density justifies the length; only a slight structure split would make it a 5.
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 that an output schema exists, the description need not detail return fields, yet it still mentions story_id, sources_count, and inline AI analysis, which are useful for interpretation. It covers parameter tuning, behavioral nuances, and explicitly points to the calendar for upcoming events. Combined with the safe annotations, an agent has everything needed to call this tool correctly under different intents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description significantly enriches parameter semantics. For example, it explains that raising min_relevance to 7 keeps roughly the release-day events and drops commentary, and it clarifies that dedupe=false keeps all syndicated reprints and that story_id matches the key alphai_trending and search tools report. These interpretations are not in the schema, adding real value.
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 states a specific verb and resource: it returns the 'market-wide macro tape' covering central-bank decisions, inflation/jobs prints, commodities, and geopolitics. It clearly distinguishes itself from sibling tools by noting that macro rows are market-wide and carry no tickers, and it explicitly routes to alphai_calendar for upcoming events. The 'novelty-first' behavior adds specificity.
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?
It gives explicit use cases ('what did the Fed say', 'any macro news today') and names an alternative ('For what is COMING — the scheduled release calendar — use alphai_calendar'). It also provides concrete tuning guidance (narrow with categories, raise min_relevance to 7 to drop commentary), which tells an agent when and how to adjust parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query AlphAI's enriched financial news feed. Pass query for full-text search — the words are matched against each article's title, named entities and summary (strict: every word required; broadened when strict finds too little, then every item carries at least two of the words and search_match.terms_matched says how many) — or set structured filters directly: ticker symbols, category, date range, and minimum relevance score (1-10). Results come back ranked by match quality, newest first among equals, each item with search_match (score, matched words in context), and pages use the next_cursor of the search. How the query was read comes back in query_interpretation: mode is 'searched'; its search block carries the text search's mode (strict / broadened / no_match / no_terms), the normalized terms, the matched count and window_from; its tickers and category list what the words ALSO read as (a company name with the issuer's registered name, a topic word) — reference only, NOT filters: pass tickers or category explicitly to restrict, and check the name so a wrong company is caught (PMI is Picard Medical, not the ISM index). Explicit tickers and category are hard filters on top of the text match; query cannot be combined with sort='ingested'. If the text search is switched off for maintenance, query falls back to being resolved to ticker/category filters and mode reads resolved / overridden / unresolved, where unresolved means the items are the general feed, NOT matches for the query. 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. Market-wide macro coverage (central-bank decisions, CPI/jobs prints, commodities, geopolitics) carries NO tickers — reach it via category=macro_economy/commodities/geopolitics or query words like 'fed', 'fomc', 'cpi', not via a ticker filter. Crypto is addressed as -USD (BTC-USD); a bare coin name nothing else owns resolves to it, same as alphai_ticker_news — but a string a stock/ETF owns (BTC = the Grayscale ETF) keeps its equity meaning: request the -USD form for the coin. Results are paginated with an opaque cursor. Set collapse_stories=true to get one row per story instead of every syndicated reprint, with sources_count: how many distinct outlets carried it. Most stories run at a single outlet, so sources_count is usually 1; a value above 1 is the signal, not the number itself. For repeated polling ('what is new since I last checked') set sort='ingested': rows come in the order they were added to the feed, next_cursor is always returned, and an empty items list means you are caught up — keep the cursor and poll again later. Delta mode carries live coverage only: history added in bulk (backfilled periods) is served by sort='published' and date filters, never as 'new'. source_type narrows the feed to an ingest source: gdelt (press), sec_form4 (insider transactions), sec_form8k (8-K current reports), sec_form6k (foreign issuers' 6-K earnings releases); item narrows to 8-K filings carrying one item code, e.g. item='5.02' for officer departures and appointments (any item of the filing, not only its primary one; implies source_type=['sec_form8k']). category already covers the two headline items (2.02 = earnings, 2.01 = mergers_acquisitions); item is for everything else. Every 8-K item carries a filing block (items, primary_item, accession_number, filed_at, event_date, exhibit_url).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Alias for query. | |
| item | No | 8-K item code (e.g. '5.02', '8.01', '1.01'): keep only 8-K filings carrying it — any item of the filing. Implies source_type=['sec_form8k']; any other source_type is an error. | |
| sort | No | published (default): newest first, next_cursor pages into older history. ingested: delta polling — rows in the order they became available, ascending; next_cursor is always returned (empty items = caught up, keep the cursor and poll later); time_published is not monotonic within a page. A cursor only works with the sort mode that issued it. | |
| limit | No | Alias for page_size. | |
| query | No | Full-text query over article titles, named entities and summaries (company names, people, topics, tickers), up to 200 characters; how it was read comes back in query_interpretation. | |
| cursor | No | Opaque cursor from a prior next_cursor. | |
| tickers | No | Restrict to news mentioning these tickers (up to 50 symbols; duplicates are ignored). | |
| to_date | No | News on/before this ISO time (UTC if naive). A bare date (2026-06-01) covers that WHOLE day, so from_date=to_date=<day> returns the day — same reading as REST /api/news/. | |
| category | No | Restrict to one news category. | |
| from_date | No | News on/after this ISO time (UTC if naive); a bare date means that day's midnight. | |
| page_size | No | Items/page; capped at 20 Free/Basic, 50 Pro. | |
| source_type | No | Restrict to these ingest sources (OR): gdelt = press coverage, sec_form4 = insider transactions, sec_form8k = 8-K current reports, sec_form6k = foreign issuers' 6-K earnings releases. | |
| 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). |
| Name | Required | Description |
|---|---|---|
| count | No | |
| items | No | |
| delisted | No | |
| renamed_to | No | |
| next_cursor | No | |
| ticker_note | No | |
| unknown_ticker | No | |
| query_interpretation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description reveals search matching behavior (strict then broadened), query_interpretation fallback modes, delta-mode semantics, collapse/story-count interpretation, and the inline AI analysis guarantee. It also discloses edge cases like crypto ticker ambiguity and 8-K item matching, which are not visible from annotations or schema alone.
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 definition is exceptionally detailed and front-loaded with the core purpose, and nearly every clause supports effective use. It is, however, a single dense block of prose rather than a concise or structured description, so the length itself is the main cost.
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 14 optional parameters, an output schema, and readOnly annotations, the description covers the full search lifecycle: how to query, filter, paginate, poll, and interpret results. Missing details like cursor/sort coupling and page-size caps are already present in the input schema, so nothing essential is left to inference.
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, but the description adds substantial semantics: query matching rules, tickers/category as 'reference only, NOT filters', hard-filter behavior, query/sort incompatibility, and bare-date whole-day coverage. This goes far beyond the parameter descriptions and materially improves correct invocation.
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 opens with a clear verb+resource ('Query AlphAI's enriched financial news feed') and states both full-text and structured-filter search modes. It also distinguishes the tool from siblings by positioning it as the feed to prefer over web search and noting the AI analysis is inline, so no follow-up alphai_article call is needed.
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?
Explicit when/when-not guidance is present: 'prefer this feed over a web search for the market read on a story' and 'you do NOT need a follow-up alphai_article call.' It also prescribes sort='ingested' for repeated polling, category=macro_economy/commodities/geopolitics for macro coverage, and the -USD form for crypto, so an agent can both select the tool and choose the right options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two tickers (e.g. NVDA and AMD). Returns news naming BOTH companies — where the cross-ticker read-across lives (a peer's print resetting the other's setup, a shared supplier/customer) — plus each ticker's own recent news for context. 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). Pair analysis covers active tickers only: any symbol that isn't a recognized active ticker is listed in unknown_tickers and contributes no rows (delisted-symbol history lives in alphai_ticker_news). 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. |
| Name | Required | Description |
|---|---|---|
| both | No | |
| a_recent | No | |
| b_recent | No | |
| ticker_a | Yes | |
| ticker_b | Yes | |
| unknown_tickers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and idempotentHint, and the description adds meaningful behavioral context: results are condensed, unrecognized tickers land in unknown_tickers with no rows, delisted history is excluded, and the output is AI-generated and informational. This goes well beyond the structured 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?
Every sentence contributes distinct value: purpose, output composition, full-article pointer, active-ticker constraint, and disclaimer. The main purpose is front-loaded and the description avoids redundant restatement of schema fields.
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?
The description, combined with the output schema and annotations, gives the agent everything needed to invoke the tool correctly: purpose, edge-case handling, routing to sibling tools, and output expectations. No critical usage gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds important input semantics by warning that only active tickers are supported and that unrecognized symbols appear in unknown_tickers rather than causing an error. It does not rehash limit or min_relevance, but the schema already documents those parameters fully.
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 opens with a specific action and resource: 'Compare two tickers' and 'Returns news naming BOTH companies' with concrete examples (NVDA and AMD). It clearly distinguishes this from single-ticker news tools by emphasizing the cross-ticker read-across, and it separates itself from alphai_ticker_news for delisted symbols.
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?
It explicitly states when to use the tool (pair/read-across analysis) and when not to: 'Pair analysis covers active tickers only' and delisted-symbol history belongs in alphai_ticker_news. It also directs users to alphai_article(uid) when a full write-up is needed, giving a clear alternative for deeper detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank news activity across the market or your saved AlphAI watchlist. Returns total story counts, model counts versus market-adjusted expectations, news tone and linked supporting headlines. Default: 20 tickers, 24h window, highest activity first. Use sentiment=negative or sort=sentiment_change with order=asc to find deteriorating news tone. Exact tickers intersect the selected scope; no alias expansion. Plans change added delay: Free 60 minutes, Basic 15 minutes, Pro none. Read as_of and freshness before describing recency; historical_preview means a fixed historical dataset, never a live reading. Only tickers with news in the chosen window appear. Missing metrics are null with a reason, not neutral. Scores describe observed news, not price forecasts or confirmed alerts. Follow next_cursor with identical filters and limit to keep the same snapshot; restart without cursor after snapshot_expired. Open a news evidence uid with alphai_article for the full enriched article. event_context adds separate issuer-CIK observations: 7-day 8-K/selected earnings 6-K filings and 30-day open-market insider clusters by latest SEC filing time, with sec_url links. For filings with has_article=true, open news_uid with alphai_article; news_title and news_published build its AlphAI URL. Article availability is frozen at the context cutoff; older snapshots default to false with null title/publication metadata. Read top-level event_context status/as_of and each row's event_context status before using counts. Null means unavailable, not zero; available does not certify complete SEC coverage. Context follows the same snapshot delay and cursors. It does not change news scores or row eligibility.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Ranking metric; stories means total stories; sentiment_change is current minus prior tone. | score |
| limit | No | Rows per page, default 20; not a ticker entitlement. | |
| min_z | No | Optional minimum descriptive activity score. | |
| order | No | Sort direction; null metrics always last. | desc |
| scope | No | Market discovery or the authenticated caller's saved watchlist. | market |
| cursor | No | Opaque next_cursor or previous_cursor, unchanged. | |
| market | No | Market filter within the selected scope. | all |
| window | No | News window ending at as_of. | 24h |
| tickers | No | Optional comma-separated exact symbols, e.g. AAPL,MSFT,BTC-USD; no tier ticker cap. | |
| sentiment | No | Positive >0.15, negative <−0.15, mixed within those bounds. Null matches only all. | all |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| total | Yes | |
| access | Yes | |
| offset | Yes | |
| window | Yes | |
| results | Yes | |
| freshness | Yes | |
| limitations | Yes | |
| next_cursor | Yes | |
| snapshot_id | Yes | |
| event_context | No | |
| point_in_time | Yes | |
| research_only | Yes | |
| previous_cursor | Yes | |
| watchlist_coverage | Yes | |
| methodology_version | Yes | |
| preview_reference_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds substantial non-obvious behavior: plan-based delay (Free 60m, Basic 15m, Pro none), as_of/freshness caveats, historical_preview semantics, null-means-unavailable reasoning, exact-ticker intersection without alias expansion, and snapshot cursor requirements. This goes far beyond the annotations and leaves no hidden behavior unaddressed.
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 long, but every sentence contributes essential operational detail for a complex tool. It is front-loaded with the core ranking function and return contents before diving into caveats. Some clauses are dense and could be broken up (e.g., the delay sentence and cursor sentence), but there is no filler or redundancy, so the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—10 parameters, cursor pagination, plan-based delays, event_context sub-observations, and snapshot semantics—the description is remarkably complete. An output schema exists, so return values need not be re-explained. The description covers scoping, ordering, filtering, pagination, freshness, null semantics, article linking, and event_context status handling, leaving no critical operational aspect unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the schema already documents every parameter including defaults, enums, and ranges. The description adds meaningful semantics beyond the schema: exact tickers intersect the selected scope with no alias expansion, cursor must be reused with identical filters to keep the same snapshot, and the sentiment parameter is tied to a concrete use case for finding deteriorating tone. This raises it above baseline without duplicating 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 opens with a specific verb and resource: 'Rank news activity across the market or your saved AlphAI watchlist.' It lists concrete returned data (story counts, model counts versus market-adjusted expectations, tone, linked headlines), which makes the tool's function unmistakable. The 'Radar' title is generic, but the description fully disambiguates the tool from a plain search or article fetcher.
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 concrete operational guidance: use sentiment=negative or sort=sentiment_change with order=asc to find deteriorating tone, and open a news evidence uid with alphai_article for full articles. It also explains defaults and cursor restriction rules. However, it does not explicitly contrast this tool with siblings like alphai_news_search or alphai_ticker_news, so the 'when not to use' side is only partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest news for a single ticker (e.g. 'AAPL'). Cursor-paginated; returns the same shape (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. min_relevance works exactly as in alphai_news_search (default 4, the full feed) — raise it to keep only what the enricher scored as material for this ticker. Set collapse_stories=true to get one row per story instead of every syndicated reprint. Sets unknown_ticker=true only for an unrecognized symbol string; a delisted symbol serves its history with delisted=true and renamed_to set when the company continues under a new ticker (querying the new ticker includes rows still tagged with the former one). Any share class of an issuer also serves rows tagged with its other listed classes (GOOGL includes rows tagged GOOG). Crypto is addressed as -USD (BTC-USD); a bare coin name nothing else owns resolves to it automatically, and when the bare string belongs to a stock/ETF instead (BTC is the Grayscale ETF), ticker_note names the coin ticker to request.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | published (default): newest first. ingested: delta polling — only rows added since your cursor, ascending; next_cursor is always returned (empty items = caught up, keep the cursor and poll later). A cursor only works with the sort mode that issued it. | |
| 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 20 Free/Basic, 50 Pro. | |
| min_relevance | No | Minimum AI relevance score, 1-10. | |
| 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). |
| Name | Required | Description |
|---|---|---|
| count | No | |
| items | No | |
| delisted | No | |
| renamed_to | No | |
| next_cursor | No | |
| ticker_note | No | |
| unknown_ticker | No | |
| query_interpretation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses substantial behavior: cursor-paginated results, identical response shape to alphai_news_search including inline AI analysis, default insider inclusion, delisted/renamed ticker handling, share-class row aggregation, and crypto symbol fallback rules. This gives an agent a detailed mental model of edge cases without needing to call the tool blindly.
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 dense but every sentence earns its place: the front-loaded purpose statement is followed by pagination, output-shape reuse, insider toggle, relevance filtering, story collapsing, and ticker-resolution edge cases. It avoids fluff and handles a complex tool in a compact, information-rich paragraph.
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 tool with 8 parameters, an output schema, and many sibling tools, the description covers the important behavioral nuances: pagination shape, AI analysis inclusion, insider default, delisted/renamed/share-class/crypto handling, and unknown-ticker signaling. Combined with the existing output schema and rich parameter descriptions in the schema, nothing critical is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantic context: min_relevance default 4 is described as the full feed and raising it keeps only enricher-scored material, collapse_stories=true is explained as one row per story instead of every syndicated reprint, and include_insider=false is framed as producing a pure non-insider feed. This goes beyond the raw schema, though it does not elaborate on every parameter.
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 opens with a specific, unambiguous purpose: 'Latest news for a single ticker (e.g. 'AAPL')'. It clearly identifies the resource (one ticker) and the operation (news feed), and implicitly distinguishes itself from broader search or insider-only tools by emphasizing single-ticker scope and the default inclusion of insider 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 gives clear context for when to use the tool: whenever you need the latest news for a single ticker. It also provides actionable parameter guidance, such as passing include_insider=false for a pure non-insider feed and raising min_relevance to keep only material stories. It does not explicitly state when to choose sibling tools like alphai_news_search or alphai_insider_news instead, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported tickers (US stocks/ETFs, crypto, and foreign listings). Optionally filter by query (prefix on ticker, substring on name, or the company's brand name where that differs from its registered one — q='spacex' finds SPCX, registered as SPACE EXPLORATION TECHNOLOGIES CORP) or by sector. currency is the trading currency (USD for US listings and crypto pairs, the local currency for foreign ones); country is the ISO alpha-2 country of domicile and is null for crypto, which has no jurisdiction of incorporation. Also answers 'when does X next report': next_report_date is the company-confirmed date of the next earnings report, in America/New_York. It is NEVER an estimate — null means AlphAI holds no confirmed date, which is not the same as the company not reporting. A confirmed date typically surfaces about five weeks ahead, so a null this far out is normal. When the report lands, alphai_earnings(ticker) returns AlphAI's read of it.
| 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). |
| Name | Required | Description |
|---|---|---|
| items | No | |
| total | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond that: the q matching semantics (ticker-prefix first, then name substring, then brand-name matching with the spacex→SPCX example), currency and country field semantics (null for crypto), and critically the next_report_date null semantics — that null means 'no confirmed date' rather than 'no report', with the ~5-week lead-time context. This prevents a real mis-invocation failure mode where an agent treats null as a fact. 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 long but every sentence earns its place — there is no filler. It is logically structured, moving from purpose to filters to field semantics to the special next_report_date capability. It is on the verbose side for a listing tool, but the subtle semantics it must convey justify the length.
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?
The tool has an output schema, so return values need no explanation. The description covers all non-obvious semantics that would cause an agent to mis-invoke: brand-name q matching, crypto country nulls, and the next_report_date null meaning with its timing context. Nothing an agent needs in order to use the filters or interpret results correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds genuine value for q by explaining brand-name matching (where a company's brand differs from its registered name, with a concrete example), which goes well beyond the schema's 'ticker-prefix matches first, then company-name substring'. limit/offset/sector are already fully covered by the schema, so the description need not repeat them.
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?
States a specific verb+resource ('List supported tickers') and defines the scope precisely (US stocks/ETFs, crypto, foreign listings). The purpose is unmistakable and clearly distinct from the sibling tools, which are all about alerts, news, earnings, radar, and watchlists rather than the ticker catalog itself.
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 one concrete routing hint — 'When the report lands, alphai_earnings(ticker) returns AlphAI's read of it' — which tells the agent where to go after using this tool. However, it never states when to use this tool versus the many siblings, nor any exclusion conditions. The usage is implied by its role as the ticker catalog rather than made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top news from the last 48h ranked by AI-assigned relevance decayed by article age (fresh stories lead; at most two stories per ticker, and market-wide macro stories — Fed/CPI, commodities, geopolitics, carrying no tickers — capped per category). 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), and each item reports story_id (the story root's uid — a stable story key, the same value the other news tools report for that story), sources_count and sources. Most stories run at a single outlet, so sources_count is usually 1; a value above 1 is the signal, not the number itself.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Stories; capped at 20 Free/Basic, 50 Pro. | |
| dedupe | No | Collapse syndicated reprints by story (default true). | |
| min_relevance | No | Min AI relevance 1-10; default 8. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description adds substantial behavioral context on top: age-decayed ranking, per-ticker caps, macro-story caps, default dedupe behavior, story_id semantics, and the meaning of sources_count. No contradiction with annotations exists.
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 dense and loaded with useful behavior, but it is a single long run-on passage with many parentheticals. The core purpose is front-loaded, and every clause adds value, though tighter structuring would improve scannability.
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 breadth of the tool—ranking, dedupe, caps, inline analysis, story_id, sources_count—the description covers all key behaviors an agent needs to call it correctly. The output schema is present, so return-value details need not be repeated. No meaningful gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds actionable parameter semantics beyond the schema: 'Lower min_relevance to surface weaker movers' and 'dedupe=false to keep all' explain how parameters affect behavior. It doesn't add much for limit, but the overall parameter guidance exceeds the baseline.
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 opens with a specific verb and resource: it lists top news from the last 48h with a clear ranking rule (AI relevance decayed by age). It further differentiates itself by noting that items carry full AI analysis inline, so no follow-up alphai_article call is needed. This clearly distinguishes it from sibling tools like alphai_article, alphai_news_search, and 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 gives an explicit trigger: 'Use this when the user asks what's moving / what's the big story.' It also gives operational guidance: lower min_relevance to surface weaker movers, and dedupe=false to keep all syndicated reprints. It does not enumerate alternatives to avoid, but the explicit use-case trigger is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize the caller's saved AlphAI watchlist in one read. Returns recent news grouped by story, a separate SEC filings section and the next confirmed earnings dates. Manage tickers at https://alphai.io/account/watchlist. Each story names the watched tickers it affects, carries a short summary and links to the article and its original source. Windows use article publication timestamps, not ingestion time; this is a ranked snapshot, not a changes cursor. Events and filings each contain up to limit items, with explicit truncation flags when more exist. Each section groups the newest 500 matching articles, then ranks by relevance, novelty and recency. Narrow hours or open the ticker feed when a section is truncated. Unknown tickers are listed separately. An empty tickers list means the caller has not saved a watchlist. A missing earnings date means no confirmed date is held, not that the company will not report. Available on every tier.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | Publication look-back in hours; default 24. | |
| limit | No | Maximum stories per section (news and filings). |
| Name | Required | Description |
|---|---|---|
| hours | Yes | |
| events | Yes | |
| filings | Yes | |
| tickers | Yes | |
| window_end | Yes | |
| generated_at | Yes | |
| window_start | Yes | |
| unknown_tickers | Yes | |
| events_truncated | No | |
| filings_truncated | No | |
| upcoming_earnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds extensive behavioral detail: publication timestamps vs ingestion time, truncation flags, ranked snapshot semantics, unknown ticker handling, and missing-date semantics. This goes well beyond the structured annotations and gives the agent a precise mental model. 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 front-loaded with the core purpose, but it is long and includes non-essential details such as the account management URL and 'Available on every tier.' While most sentences add behavioral value, the extra operational noise slightly dilutes conciseness, so it earns a 3 rather than higher.
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 two-parameter, read-only tool with a full output schema and rich annotations, the description covers all practical edge cases: truncation, empty watchlist, missing earnings dates, unknown tickers, and ranking behavior. The only minor omission is explicit pagination details, but the output schema and truncation flags cover that, so the description is complete enough.
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 adds extra semantics by clarifying that 'Windows use article publication timestamps, not ingestion time' (defines hours) and that 'Events and filings each contain up to limit items' (defines scope of limit). This adds meaning beyond the schema, so a 4 is warranted.
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?
States a specific verb and resource: 'Summarize the caller's saved AlphAI watchlist in one read.' It further clarifies outputs: recent news grouped by story, SEC filings section, and earnings dates, which distinguishes it from sibling tools like alphai_ticker_news or alphai_news_search. The 'caller's saved watchlist' scoping makes the tool's unique role clear.
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 on when to use this tool: as a one-read summary of the saved watchlist, and explicitly advises 'Narrow hours or open the ticker feed when a section is truncated.' It also clarifies that it is a ranked snapshot, not a changes cursor, which implies it isn't for change detection. It does not explicitly name alternative tools or state when not to use it, so not a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. When the article has a published SEC earnings read, text also includes its reported metrics with year-over-year and sequential comparisons, segments, guidance, concerns and missing items. Raises not_found for an unknown id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Article id from a search result. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description correctly adds non-obvious behavior: it returns a digest rather than the full body, includes SEC earnings data conditionally, and raises not_found for unknown ids. 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 information-dense and front-loaded with the core action, followed by return behavior, conditional content, and error handling. The opening phrase 'ChatGPT connector contract' is slightly redundant with the title, but every other clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter fetch tool with rich annotations and an output schema, the description covers the input source, the exact return shape, a conditional enrichment behavior, and error semantics. An agent has enough context to invoke the tool correctly without needing to open sibling schemas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single id parameter, and the description reinforces the same guidance ('id returned from search') without adding new syntax or format details. Baseline 3 is appropriate because the schema already carries the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'fetch one article by the id returned from search.' It clearly differentiates itself by saying it returns the enriched digest and 'not the full article body,' which separates it from sibling tools like alphai_article and 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 usage context: use after search, with an id returned from search, when you want the enriched digest rather than the full article body. It does not explicitly name an alternative tool for retrieving the full body, so it stops short of full when-to-use vs. alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ChatGPT connector contract: search AlphAI'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 (up to 300 characters). |
| Name | Required | Description |
|---|---|---|
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds behavioral detail beyond annotations: it explains entity resolution (tickers, companies, topics), the fallback to freshest stories when nothing is recognized, and that each result carries an id for the fetch tool. This provides useful context without contradicting 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?
The description is three sentences, front-loaded with the core purpose, and includes necessary usage guidance, behavioral notes, and a pointer to an alternative. No fluff or redundancy. It is concise while covering essential information, though it could arguably be slightly tightened without losing meaning.
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 (one parameter), existing output schema, and annotations that cover safety, the description is nearly complete. It covers query interpretation, fallback behavior, and the link to the fetch tool, and it names an alternative. The only minor gap is that it doesn't explicitly describe the output format, but the output schema handles that, so the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (the 'query' parameter has a basic description). The tool description adds semantic meaning by explaining that the query is natural-language and how it is interpreted (resolved to structured filters, with a fallback). This goes beyond the schema's simple 'Natural-language search query' description, giving the agent a richer understanding of the parameter's role.
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 states a specific verb and resource: 'search AlphAI's AI-enriched financial news' with a natural-language query. It explicitly distinguishes itself from the sibling alphai_news_search by saying 'For precise filtered queries prefer alphai_news_search.' This makes the tool's scope and differentiation clear.
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 explicit usage guidance: it explains that the query is natural-language and that known entities are resolved to filters, while a query with no known names returns freshest high-relevance stories. It also explicitly names the alternative (alphai_news_search) and the condition for preferring it ('precise filtered queries'). This covers when 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
alphai_insider_clusters1 field changedOutput schema / properties / results / items / properties / buyers_detail / items / properties / reasonAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "placement",
+ "offering",
+ "private"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_alerts_subscribe2 fields changedInput schema / properties / ticker / maxLengthAdded value: +16Input schema / properties / ticker / patternAdded value: +"^[A-Za-z0-9.\\-]+$"alphai_alerts_unsubscribe2 fields changedInput schema / properties / ticker / maxLengthAdded value: +16Input schema / properties / ticker / patternAdded value: +"^[A-Za-z0-9.\\-]+$"alphai_article1 field changedInput schema / properties / uid / maxLengthAdded value: +64alphai_earnings2 fields changedInput schema / properties / ticker / maxLengthAdded value: +16Input schema / properties / ticker / patternAdded value: +"^[A-Za-z0-9.\\-]+$"alphai_insider_news2 fields changedInput schema / properties / cursor / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 1024,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / ticker / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 16,
+ "pattern": "^[A-Za-z0-9.\\-]+$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]alphai_news_search6 fields changedInput schema / properties / cursor / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 1024,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / q / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 200,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / query / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 200,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / query / descriptionPrevious value: -"Full-text query over article titles, named entities and summaries (company names, people, topics, tickers); how it was read comes back in query_interpretation."New value: +"Full-text query over article titles, named entities and summaries (company names, people, topics, tickers), up to 200 characters; how it was read comes back in query_interpretation."Input schema / properties / tickers / anyOfPrevious value: -[
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "maxLength": 16,
+ "pattern": "^[A-Za-z0-9.\\-]+$",
+ "type": "string"
+ },
+ "maxItems": 50,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / tickers / descriptionPrevious value: -"Restrict to news mentioning these tickers."New value: +"Restrict to news mentioning these tickers (up to 50 symbols; duplicates are ignored)."alphai_pair_analysis4 fields changedInput schema / properties / ticker_a / maxLengthAdded value: +16Input schema / properties / ticker_a / patternAdded value: +"^[A-Za-z0-9.\\-]+$"Input schema / properties / ticker_b / maxLengthAdded value: +16Input schema / properties / ticker_b / patternAdded value: +"^[A-Za-z0-9.\\-]+$"alphai_ticker_news3 fields changedInput schema / properties / cursor / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 1024,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / ticker / maxLengthAdded value: +16Input schema / properties / ticker / patternAdded value: +"^[A-Za-z0-9.\\-]+$"alphai_tickers2 fields changedInput schema / properties / q / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / sector / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]fetch1 field changedInput schema / properties / id / maxLengthAdded value: +64search2 fields changedInput schema / properties / query / descriptionPrevious value: -"Natural-language search query."New value: +"Natural-language search query (up to 300 characters)."Input schema / properties / query / maxLengthAdded value: +300alphai_radar1 field changedOutput schema / properties / results / items / properties / event_context / anyOfPrevious value: -[
- {
- "properties": {
- "cik": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "cluster_buys": {
- "default": [],
- "items": {
- "properties": {
- "buyers": {
- "type": "integer"
- },
- "evidence": {
- "items": {
- "properties": {
- "accession_number": {
- "type": "string"
- },
- "filed_at": {
- "format": "date-time",
- "type": "string"
- },
- "sec_url": {
- "type": "string"
- }
- },
- "required": [
- "accession_number",
- "filed_at",
- "sec_url"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "evidence_truncated": {
- "type": "boolean"
- },
- "filings_count": {
- "type": "integer"
- },
- "known_at": {
- "format": "date-time",
- "type": "string"
- },
- "officer_director_buyers": {
- "type": "integer"
- },
- "pattern": {
- "const": "open_market",
- "default": "open_market",
- "type": "string"
- },
- "window_end": {
- "format": "date",
- "type": "string"
- },
- "window_start": {
- "format": "date",
- "type": "string"
- }
- },
- "required": [
- "window_start",
- "window_end",
- "known_at",
- "buyers",
- "officer_director_buyers",
- "filings_count",
- "evidence",
- "evidence_truncated"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "cluster_buys_count": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "filings": {
- "default": [],
- "items": {
- "properties": {
- "accession_number": {
- "type": "string"
- },
- "event_date": {
- "anyOf": [
- {
- "format": "date",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "filed_at": {
- "format": "date-time",
- "type": "string"
- },
- "form": {
- "enum": [
- "8-K",
- "6-K"
- ],
- "type": "string"
- },
- "items": {
- "default": [],
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "kind": {
- "anyOf": [
- {
- "const": "earnings_release",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "news_uid": {
- "type": "string"
- },
- "observed_at": {
- "format": "date-time",
- "type": "string"
- },
- "period_label": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "primary_item": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "sec_url": {
- "type": "string"
- }
- },
- "required": [
- "form",
- "accession_number",
- "filed_at",
- "observed_at",
- "sec_url",
- "news_uid"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "filings_count": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "reason": {
- "anyOf": [
- {
- "enum": [
- "non_sec_symbol",
- "unknown_symbol",
- "missing_cik",
- "issuer_changed"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "status": {
- "enum": [
- "available",
- "unsupported",
- "unavailable"
- ],
- "type": "string"
- },
- "ticker": {
- "type": "string"
- }
- },
- "required": [
- "ticker",
- "cik",
- "status"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "properties": {
+ "cik": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "cluster_buys": {
+ "default": [],
+ "items": {
+ "properties": {
+ "buyers": {
+ "type": "integer"
+ },
+ "evidence": {
+ "items": {
+ "properties": {
+ "accession_number": {
+ "type": "string"
+ },
+ "filed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "sec_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "accession_number",
+ "filed_at",
+ "sec_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "evidence_truncated": {
+ "type": "boolean"
+ },
+ "filings_count": {
+ "type": "integer"
+ },
+ "known_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "officer_director_buyers": {
+ "type": "integer"
+ },
+ "pattern": {
+ "const": "open_market",
+ "default": "open_market",
+ "type": "string"
+ },
+ "window_end": {
+ "format": "date",
+ "type": "string"
+ },
+ "window_start": {
+ "format": "date",
+ "type": "string"
+ }
+ },
+ "required": [
+ "window_start",
+ "window_end",
+ "known_at",
+ "buyers",
+ "officer_director_buyers",
+ "filings_count",
+ "evidence",
+ "evidence_truncated"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "cluster_buys_count": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "filings": {
+ "default": [],
+ "items": {
+ "properties": {
+ "accession_number": {
+ "type": "string"
+ },
+ "event_date": {
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "filed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "form": {
+ "enum": [
+ "8-K",
+ "6-K"
+ ],
+ "type": "string"
+ },
+ "has_article": {
+ "default": false,
+ "description": "An enriched article existed before the context cutoff. False on older snapshots without metadata.",
+ "type": "boolean"
+ },
+ "items": {
+ "default": [],
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "kind": {
+ "anyOf": [
+ {
+ "const": "earnings_release",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "news_published": {
+ "anyOf": [
+ {
+ "format": "date-time",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Article publication time for its AlphAI URL."
+ },
+ "news_title": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Article title frozen at the context cutoff."
+ },
+ "news_uid": {
+ "type": "string"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "period_label": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "primary_item": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "sec_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "form",
+ "accession_number",
+ "filed_at",
+ "observed_at",
+ "sec_url",
+ "news_uid"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "filings_count": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "enum": [
+ "non_sec_symbol",
+ "unknown_symbol",
+ "missing_cik",
+ "issuer_changed"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "status": {
+ "enum": [
+ "available",
+ "unsupported",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "ticker": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ticker",
+ "cik",
+ "status"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]alphai_insider_news1 field changedOutput schema / properties / query_interpretation / anyOfPrevious value: -[
- {
- "description": "How ``alphai_news_search`` read a free-text ``query`` — the echo that makes\na resolver miss legible. Before it, a query read as the wrong company or\ndiscarded entirely came back indistinguishable from a hit\n(issues/2026-08-16-freetext-query-resolves-jane-street-to-janl.md).\n\n``mode``: ``resolved`` — at least one query word became a filter that is\napplied to the items; ``overridden`` — the query resolved, but explicit\n``tickers``/``category`` replaced every filter it produced; ``unresolved`` —\nno query word matched a ticker, company name or topic word, so the items\nare NOT matches for the query (``note`` says what they are instead).\n``ignored_terms`` lists the content words that matched nothing; stopwords\nare dropped silently. ``note`` is one or two plain sentences an agent can act\non, same role as ``ticker_note``.",
- "properties": {
- "category": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "category_term": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "ignored_terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "mode": {
- "enum": [
- "resolved",
- "overridden",
- "unresolved"
- ],
- "type": "string"
- },
- "note": {
- "default": "",
- "type": "string"
- },
- "search": {
- "anyOf": [
- {
- "description": "How the text search read the query (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 2): ``strict`` = every term required; ``broadened`` = fewer strict\nmatches than the threshold, so any rare term plus at least two of the\nterms; ``no_match``; ``no_terms``. ``sort`` is ``published`` when every\nterm is a very common word (newest matches, not best). ``terms`` are the\nnormalized (stemmed) lexemes the index holds. ``matched`` counts the\nvisible matches inside the bounded candidate set, never a global total.",
- "properties": {
- "engine": {
- "default": "postgres",
- "enum": [
- "postgres",
- "meilisearch"
- ],
- "type": "string"
- },
- "matched": {
- "default": 0,
- "type": "integer"
- },
- "mode": {
- "enum": [
- "strict",
- "broadened",
- "no_match",
- "no_terms"
- ],
- "type": "string"
- },
- "optional_terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "required_terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "sort": {
- "enum": [
- "relevance",
- "published"
- ],
- "type": "string"
- },
- "terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "window_from": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- }
- },
- "required": [
- "mode",
- "sort"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "tickers": {
- "items": {
- "description": "One ticker a free-text ``query`` resolved to (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 1). ``name`` is the issuer's registered name, so an agent can see that\n\"PMI\" was read as Picard Medical rather than the ISM purchasing-managers\nindex; ``term`` is the query word that produced it (share-class siblings\ninherit the seed word's term).",
- "properties": {
- "name": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "term": {
- "type": "string"
- },
- "ticker": {
- "type": "string"
- }
- },
- "required": [
- "ticker",
- "term"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "mode"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "How ``alphai_news_search`` read a free-text ``query`` — the echo that makes\na resolver miss legible. Before it, a query read as the wrong company or\ndiscarded entirely came back indistinguishable from a hit\n(issues/2026-08-16-freetext-query-resolves-jane-street-to-janl.md).\n\n``mode``: ``searched`` — the text search served the items\n(``NEWS_SEARCH_MODE=on``, the normal state since 2026-09-23): ``search``\nsays what selected them, ``tickers``/``category`` only say what the words\nwere ALSO read as (reference, never a filter) and ``ignored_terms`` is\nempty, because nothing was ignored — the whole text was searched. Before\nthis (review finding 1a/1b, 2026-09-23) the text path echoed the\nresolver's ``resolved`` + its ``ignored_terms`` next to a ``search`` block\nwhose ``terms`` were those very words, and a read category looked applied\nwhile nothing but the text filtered the items. The resolver modes describe\nthe fallback when the text search is switched off: ``resolved`` — at least\none query word became a filter that is applied to the items;\n``overridden`` — the query resolved, but explicit ``tickers``/``category``\nreplaced every filter it produced; ``unresolved`` — no query word matched a\nticker, company name or topic word, so the items are NOT matches for the\nquery (``note`` says what they are instead). ``ignored_terms`` then lists\nthe content words that matched nothing; stopwords are dropped silently.\n``note`` is one or two plain sentences an agent can act on, same role as\n``ticker_note``.",
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "category_term": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "ignored_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "mode": {
+ "enum": [
+ "searched",
+ "resolved",
+ "overridden",
+ "unresolved"
+ ],
+ "type": "string"
+ },
+ "note": {
+ "default": "",
+ "type": "string"
+ },
+ "search": {
+ "anyOf": [
+ {
+ "description": "How the text search read the query (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 2): ``strict`` = every term required; ``broadened`` = fewer strict\nmatches than the threshold, so the most common words were dropped first\nand every item carries at least two of the terms; ``no_match``;\n``no_terms``. ``sort`` is ``published`` when every term is a very common\nword (newest matches, not best). ``terms`` are the normalized words that\nwere searched. ``required_terms`` is filled only when the search reports\nwhich words every broadened row had to carry (the Postgres path does, the\nengine does not) — ``search_match.terms_matched`` on each item is the\ncount to trust. ``matched`` counts the visible matches inside the bounded\ncandidate set, never a global total. Which engine answered is NOT part of\nthe contract: it goes to the search log (``ranking_version``). The\n``engine`` field that shipped with 1.41.0 was read by an external review\nas an implementation leak, and it was one — a client has no action on\n\"meilisearch\" (issues/2026-09-23-news-search-review-triage.md).",
+ "properties": {
+ "matched": {
+ "default": 0,
+ "type": "integer"
+ },
+ "mode": {
+ "enum": [
+ "strict",
+ "broadened",
+ "no_match",
+ "no_terms"
+ ],
+ "type": "string"
+ },
+ "optional_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "required_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sort": {
+ "enum": [
+ "relevance",
+ "published"
+ ],
+ "type": "string"
+ },
+ "terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "window_from": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ }
+ },
+ "required": [
+ "mode",
+ "sort"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "tickers": {
+ "items": {
+ "description": "One ticker a free-text ``query`` resolved to (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 1). ``name`` is the issuer's registered name, so an agent can see that\n\"PMI\" was read as Picard Medical rather than the ISM purchasing-managers\nindex; ``term`` is the query word that produced it (share-class siblings\ninherit the seed word's term).",
+ "properties": {
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "term": {
+ "type": "string"
+ },
+ "ticker": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ticker",
+ "term"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "mode"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]alphai_news_search2 fields changedInput schema / properties / query / descriptionPrevious value: -"Free-text query (company names / tickers / topic words) resolved to ticker + category filters; how it was read comes back in query_interpretation."New value: +"Full-text query over article titles, named entities and summaries (company names, people, topics, tickers); how it was read comes back in query_interpretation."Output schema / properties / query_interpretation / anyOfPrevious value: -[
- {
- "description": "How ``alphai_news_search`` read a free-text ``query`` — the echo that makes\na resolver miss legible. Before it, a query read as the wrong company or\ndiscarded entirely came back indistinguishable from a hit\n(issues/2026-08-16-freetext-query-resolves-jane-street-to-janl.md).\n\n``mode``: ``resolved`` — at least one query word became a filter that is\napplied to the items; ``overridden`` — the query resolved, but explicit\n``tickers``/``category`` replaced every filter it produced; ``unresolved`` —\nno query word matched a ticker, company name or topic word, so the items\nare NOT matches for the query (``note`` says what they are instead).\n``ignored_terms`` lists the content words that matched nothing; stopwords\nare dropped silently. ``note`` is one or two plain sentences an agent can act\non, same role as ``ticker_note``.",
- "properties": {
- "category": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "category_term": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "ignored_terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "mode": {
- "enum": [
- "resolved",
- "overridden",
- "unresolved"
- ],
- "type": "string"
- },
- "note": {
- "default": "",
- "type": "string"
- },
- "search": {
- "anyOf": [
- {
- "description": "How the text search read the query (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 2): ``strict`` = every term required; ``broadened`` = fewer strict\nmatches than the threshold, so any rare term plus at least two of the\nterms; ``no_match``; ``no_terms``. ``sort`` is ``published`` when every\nterm is a very common word (newest matches, not best). ``terms`` are the\nnormalized (stemmed) lexemes the index holds. ``matched`` counts the\nvisible matches inside the bounded candidate set, never a global total.",
- "properties": {
- "engine": {
- "default": "postgres",
- "enum": [
- "postgres",
- "meilisearch"
- ],
- "type": "string"
- },
- "matched": {
- "default": 0,
- "type": "integer"
- },
- "mode": {
- "enum": [
- "strict",
- "broadened",
- "no_match",
- "no_terms"
- ],
- "type": "string"
- },
- "optional_terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "required_terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "sort": {
- "enum": [
- "relevance",
- "published"
- ],
- "type": "string"
- },
- "terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "window_from": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- }
- },
- "required": [
- "mode",
- "sort"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "tickers": {
- "items": {
- "description": "One ticker a free-text ``query`` resolved to (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 1). ``name`` is the issuer's registered name, so an agent can see that\n\"PMI\" was read as Picard Medical rather than the ISM purchasing-managers\nindex; ``term`` is the query word that produced it (share-class siblings\ninherit the seed word's term).",
- "properties": {
- "name": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "term": {
- "type": "string"
- },
- "ticker": {
- "type": "string"
- }
- },
- "required": [
- "ticker",
- "term"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "mode"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "How ``alphai_news_search`` read a free-text ``query`` — the echo that makes\na resolver miss legible. Before it, a query read as the wrong company or\ndiscarded entirely came back indistinguishable from a hit\n(issues/2026-08-16-freetext-query-resolves-jane-street-to-janl.md).\n\n``mode``: ``searched`` — the text search served the items\n(``NEWS_SEARCH_MODE=on``, the normal state since 2026-09-23): ``search``\nsays what selected them, ``tickers``/``category`` only say what the words\nwere ALSO read as (reference, never a filter) and ``ignored_terms`` is\nempty, because nothing was ignored — the whole text was searched. Before\nthis (review finding 1a/1b, 2026-09-23) the text path echoed the\nresolver's ``resolved`` + its ``ignored_terms`` next to a ``search`` block\nwhose ``terms`` were those very words, and a read category looked applied\nwhile nothing but the text filtered the items. The resolver modes describe\nthe fallback when the text search is switched off: ``resolved`` — at least\none query word became a filter that is applied to the items;\n``overridden`` — the query resolved, but explicit ``tickers``/``category``\nreplaced every filter it produced; ``unresolved`` — no query word matched a\nticker, company name or topic word, so the items are NOT matches for the\nquery (``note`` says what they are instead). ``ignored_terms`` then lists\nthe content words that matched nothing; stopwords are dropped silently.\n``note`` is one or two plain sentences an agent can act on, same role as\n``ticker_note``.",
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "category_term": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "ignored_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "mode": {
+ "enum": [
+ "searched",
+ "resolved",
+ "overridden",
+ "unresolved"
+ ],
+ "type": "string"
+ },
+ "note": {
+ "default": "",
+ "type": "string"
+ },
+ "search": {
+ "anyOf": [
+ {
+ "description": "How the text search read the query (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 2): ``strict`` = every term required; ``broadened`` = fewer strict\nmatches than the threshold, so the most common words were dropped first\nand every item carries at least two of the terms; ``no_match``;\n``no_terms``. ``sort`` is ``published`` when every term is a very common\nword (newest matches, not best). ``terms`` are the normalized words that\nwere searched. ``required_terms`` is filled only when the search reports\nwhich words every broadened row had to carry (the Postgres path does, the\nengine does not) — ``search_match.terms_matched`` on each item is the\ncount to trust. ``matched`` counts the visible matches inside the bounded\ncandidate set, never a global total. Which engine answered is NOT part of\nthe contract: it goes to the search log (``ranking_version``). The\n``engine`` field that shipped with 1.41.0 was read by an external review\nas an implementation leak, and it was one — a client has no action on\n\"meilisearch\" (issues/2026-09-23-news-search-review-triage.md).",
+ "properties": {
+ "matched": {
+ "default": 0,
+ "type": "integer"
+ },
+ "mode": {
+ "enum": [
+ "strict",
+ "broadened",
+ "no_match",
+ "no_terms"
+ ],
+ "type": "string"
+ },
+ "optional_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "required_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sort": {
+ "enum": [
+ "relevance",
+ "published"
+ ],
+ "type": "string"
+ },
+ "terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "window_from": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ }
+ },
+ "required": [
+ "mode",
+ "sort"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "tickers": {
+ "items": {
+ "description": "One ticker a free-text ``query`` resolved to (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 1). ``name`` is the issuer's registered name, so an agent can see that\n\"PMI\" was read as Picard Medical rather than the ISM purchasing-managers\nindex; ``term`` is the query word that produced it (share-class siblings\ninherit the seed word's term).",
+ "properties": {
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "term": {
+ "type": "string"
+ },
+ "ticker": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ticker",
+ "term"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "mode"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]alphai_ticker_news1 field changedOutput schema / properties / query_interpretation / anyOfPrevious value: -[
- {
- "description": "How ``alphai_news_search`` read a free-text ``query`` — the echo that makes\na resolver miss legible. Before it, a query read as the wrong company or\ndiscarded entirely came back indistinguishable from a hit\n(issues/2026-08-16-freetext-query-resolves-jane-street-to-janl.md).\n\n``mode``: ``resolved`` — at least one query word became a filter that is\napplied to the items; ``overridden`` — the query resolved, but explicit\n``tickers``/``category`` replaced every filter it produced; ``unresolved`` —\nno query word matched a ticker, company name or topic word, so the items\nare NOT matches for the query (``note`` says what they are instead).\n``ignored_terms`` lists the content words that matched nothing; stopwords\nare dropped silently. ``note`` is one or two plain sentences an agent can act\non, same role as ``ticker_note``.",
- "properties": {
- "category": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "category_term": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "ignored_terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "mode": {
- "enum": [
- "resolved",
- "overridden",
- "unresolved"
- ],
- "type": "string"
- },
- "note": {
- "default": "",
- "type": "string"
- },
- "search": {
- "anyOf": [
- {
- "description": "How the text search read the query (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 2): ``strict`` = every term required; ``broadened`` = fewer strict\nmatches than the threshold, so any rare term plus at least two of the\nterms; ``no_match``; ``no_terms``. ``sort`` is ``published`` when every\nterm is a very common word (newest matches, not best). ``terms`` are the\nnormalized (stemmed) lexemes the index holds. ``matched`` counts the\nvisible matches inside the bounded candidate set, never a global total.",
- "properties": {
- "engine": {
- "default": "postgres",
- "enum": [
- "postgres",
- "meilisearch"
- ],
- "type": "string"
- },
- "matched": {
- "default": 0,
- "type": "integer"
- },
- "mode": {
- "enum": [
- "strict",
- "broadened",
- "no_match",
- "no_terms"
- ],
- "type": "string"
- },
- "optional_terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "required_terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "sort": {
- "enum": [
- "relevance",
- "published"
- ],
- "type": "string"
- },
- "terms": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "window_from": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- }
- },
- "required": [
- "mode",
- "sort"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "tickers": {
- "items": {
- "description": "One ticker a free-text ``query`` resolved to (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 1). ``name`` is the issuer's registered name, so an agent can see that\n\"PMI\" was read as Picard Medical rather than the ISM purchasing-managers\nindex; ``term`` is the query word that produced it (share-class siblings\ninherit the seed word's term).",
- "properties": {
- "name": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "term": {
- "type": "string"
- },
- "ticker": {
- "type": "string"
- }
- },
- "required": [
- "ticker",
- "term"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "mode"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "How ``alphai_news_search`` read a free-text ``query`` — the echo that makes\na resolver miss legible. Before it, a query read as the wrong company or\ndiscarded entirely came back indistinguishable from a hit\n(issues/2026-08-16-freetext-query-resolves-jane-street-to-janl.md).\n\n``mode``: ``searched`` — the text search served the items\n(``NEWS_SEARCH_MODE=on``, the normal state since 2026-09-23): ``search``\nsays what selected them, ``tickers``/``category`` only say what the words\nwere ALSO read as (reference, never a filter) and ``ignored_terms`` is\nempty, because nothing was ignored — the whole text was searched. Before\nthis (review finding 1a/1b, 2026-09-23) the text path echoed the\nresolver's ``resolved`` + its ``ignored_terms`` next to a ``search`` block\nwhose ``terms`` were those very words, and a read category looked applied\nwhile nothing but the text filtered the items. The resolver modes describe\nthe fallback when the text search is switched off: ``resolved`` — at least\none query word became a filter that is applied to the items;\n``overridden`` — the query resolved, but explicit ``tickers``/``category``\nreplaced every filter it produced; ``unresolved`` — no query word matched a\nticker, company name or topic word, so the items are NOT matches for the\nquery (``note`` says what they are instead). ``ignored_terms`` then lists\nthe content words that matched nothing; stopwords are dropped silently.\n``note`` is one or two plain sentences an agent can act on, same role as\n``ticker_note``.",
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "category_term": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "ignored_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "mode": {
+ "enum": [
+ "searched",
+ "resolved",
+ "overridden",
+ "unresolved"
+ ],
+ "type": "string"
+ },
+ "note": {
+ "default": "",
+ "type": "string"
+ },
+ "search": {
+ "anyOf": [
+ {
+ "description": "How the text search read the query (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 2): ``strict`` = every term required; ``broadened`` = fewer strict\nmatches than the threshold, so the most common words were dropped first\nand every item carries at least two of the terms; ``no_match``;\n``no_terms``. ``sort`` is ``published`` when every term is a very common\nword (newest matches, not best). ``terms`` are the normalized words that\nwere searched. ``required_terms`` is filled only when the search reports\nwhich words every broadened row had to carry (the Postgres path does, the\nengine does not) — ``search_match.terms_matched`` on each item is the\ncount to trust. ``matched`` counts the visible matches inside the bounded\ncandidate set, never a global total. Which engine answered is NOT part of\nthe contract: it goes to the search log (``ranking_version``). The\n``engine`` field that shipped with 1.41.0 was read by an external review\nas an implementation leak, and it was one — a client has no action on\n\"meilisearch\" (issues/2026-09-23-news-search-review-triage.md).",
+ "properties": {
+ "matched": {
+ "default": 0,
+ "type": "integer"
+ },
+ "mode": {
+ "enum": [
+ "strict",
+ "broadened",
+ "no_match",
+ "no_terms"
+ ],
+ "type": "string"
+ },
+ "optional_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "required_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sort": {
+ "enum": [
+ "relevance",
+ "published"
+ ],
+ "type": "string"
+ },
+ "terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "window_from": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ }
+ },
+ "required": [
+ "mode",
+ "sort"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "tickers": {
+ "items": {
+ "description": "One ticker a free-text ``query`` resolved to (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 1). ``name`` is the issuer's registered name, so an agent can see that\n\"PMI\" was read as Picard Medical rather than the ISM purchasing-managers\nindex; ``term`` is the query word that produced it (share-class siblings\ninherit the seed word's term).",
+ "properties": {
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "term": {
+ "type": "string"
+ },
+ "ticker": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ticker",
+ "term"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "mode"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]alphai_actionable_now1 field changedOutput schema / properties / result / items / properties / search_matchAdded 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
+}alphai_article1 field changedOutput schema / properties / search_matchAdded 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
+}alphai_insider_news2 fields changedOutput schema / properties / items / items / properties / search_matchAdded 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
+}Output schema / properties / query_interpretationAdded value: +{
+ "anyOf": [
+ {
+ "description": "How ``alphai_news_search`` read a free-text ``query`` — the echo that makes\na resolver miss legible. Before it, a query read as the wrong company or\ndiscarded entirely came back indistinguishable from a hit\n(issues/2026-08-16-freetext-query-resolves-jane-street-to-janl.md).\n\n``mode``: ``resolved`` — at least one query word became a filter that is\napplied to the items; ``overridden`` — the query resolved, but explicit\n``tickers``/``category`` replaced every filter it produced; ``unresolved`` —\nno query word matched a ticker, company name or topic word, so the items\nare NOT matches for the query (``note`` says what they are instead).\n``ignored_terms`` lists the content words that matched nothing; stopwords\nare dropped silently. ``note`` is one or two plain sentences an agent can act\non, same role as ``ticker_note``.",
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "category_term": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "ignored_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "mode": {
+ "enum": [
+ "resolved",
+ "overridden",
+ "unresolved"
+ ],
+ "type": "string"
+ },
+ "note": {
+ "default": "",
+ "type": "string"
+ },
+ "search": {
+ "anyOf": [
+ {
+ "description": "How the text search read the query (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 2): ``strict`` = every term required; ``broadened`` = fewer strict\nmatches than the threshold, so any rare term plus at least two of the\nterms; ``no_match``; ``no_terms``. ``sort`` is ``published`` when every\nterm is a very common word (newest matches, not best). ``terms`` are the\nnormalized (stemmed) lexemes the index holds. ``matched`` counts the\nvisible matches inside the bounded candidate set, never a global total.",
+ "properties": {
+ "engine": {
+ "default": "postgres",
+ "enum": [
+ "postgres",
+ "meilisearch"
+ ],
+ "type": "string"
+ },
+ "matched": {
+ "default": 0,
+ "type": "integer"
+ },
+ "mode": {
+ "enum": [
+ "strict",
+ "broadened",
+ "no_match",
+ "no_terms"
+ ],
+ "type": "string"
+ },
+ "optional_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "required_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sort": {
+ "enum": [
+ "relevance",
+ "published"
+ ],
+ "type": "string"
+ },
+ "terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "window_from": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ }
+ },
+ "required": [
+ "mode",
+ "sort"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "tickers": {
+ "items": {
+ "description": "One ticker a free-text ``query`` resolved to (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 1). ``name`` is the issuer's registered name, so an agent can see that\n\"PMI\" was read as Picard Medical rather than the ISM purchasing-managers\nindex; ``term`` is the query word that produced it (share-class siblings\ninherit the seed word's term).",
+ "properties": {
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "term": {
+ "type": "string"
+ },
+ "ticker": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ticker",
+ "term"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "mode"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_macro1 field changedOutput schema / properties / result / items / properties / search_matchAdded 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
+}alphai_news_search3 fields changedInput schema / properties / query / descriptionPrevious value: -"Free-text query (company names / tickers / topic words) resolved to ticker + category filters."New value: +"Free-text query (company names / tickers / topic words) resolved to ticker + category filters; how it was read comes back in query_interpretation."Output schema / properties / items / items / properties / search_matchAdded 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
+}Output schema / properties / query_interpretationAdded value: +{
+ "anyOf": [
+ {
+ "description": "How ``alphai_news_search`` read a free-text ``query`` — the echo that makes\na resolver miss legible. Before it, a query read as the wrong company or\ndiscarded entirely came back indistinguishable from a hit\n(issues/2026-08-16-freetext-query-resolves-jane-street-to-janl.md).\n\n``mode``: ``resolved`` — at least one query word became a filter that is\napplied to the items; ``overridden`` — the query resolved, but explicit\n``tickers``/``category`` replaced every filter it produced; ``unresolved`` —\nno query word matched a ticker, company name or topic word, so the items\nare NOT matches for the query (``note`` says what they are instead).\n``ignored_terms`` lists the content words that matched nothing; stopwords\nare dropped silently. ``note`` is one or two plain sentences an agent can act\non, same role as ``ticker_note``.",
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "category_term": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "ignored_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "mode": {
+ "enum": [
+ "resolved",
+ "overridden",
+ "unresolved"
+ ],
+ "type": "string"
+ },
+ "note": {
+ "default": "",
+ "type": "string"
+ },
+ "search": {
+ "anyOf": [
+ {
+ "description": "How the text search read the query (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 2): ``strict`` = every term required; ``broadened`` = fewer strict\nmatches than the threshold, so any rare term plus at least two of the\nterms; ``no_match``; ``no_terms``. ``sort`` is ``published`` when every\nterm is a very common word (newest matches, not best). ``terms`` are the\nnormalized (stemmed) lexemes the index holds. ``matched`` counts the\nvisible matches inside the bounded candidate set, never a global total.",
+ "properties": {
+ "engine": {
+ "default": "postgres",
+ "enum": [
+ "postgres",
+ "meilisearch"
+ ],
+ "type": "string"
+ },
+ "matched": {
+ "default": 0,
+ "type": "integer"
+ },
+ "mode": {
+ "enum": [
+ "strict",
+ "broadened",
+ "no_match",
+ "no_terms"
+ ],
+ "type": "string"
+ },
+ "optional_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "required_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sort": {
+ "enum": [
+ "relevance",
+ "published"
+ ],
+ "type": "string"
+ },
+ "terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "window_from": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ }
+ },
+ "required": [
+ "mode",
+ "sort"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "tickers": {
+ "items": {
+ "description": "One ticker a free-text ``query`` resolved to (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 1). ``name`` is the issuer's registered name, so an agent can see that\n\"PMI\" was read as Picard Medical rather than the ISM purchasing-managers\nindex; ``term`` is the query word that produced it (share-class siblings\ninherit the seed word's term).",
+ "properties": {
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "term": {
+ "type": "string"
+ },
+ "ticker": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ticker",
+ "term"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "mode"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_pair_analysis3 fields changedOutput schema / properties / a_recent / items / properties / search_matchAdded 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
+}Output schema / properties / b_recent / items / properties / search_matchAdded 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
+}Output schema / properties / both / items / properties / search_matchAdded 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
+}alphai_radar2 fields changedOutput schema / properties / event_contextAdded value: +{
+ "properties": {
+ "age_seconds": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "as_of": {
+ "anyOf": [
+ {
+ "format": "date-time",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "cluster_lookback_days": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "filings_lookback_days": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "generated_at": {
+ "anyOf": [
+ {
+ "format": "date-time",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "identity_scope": {
+ "const": "issuer_cik",
+ "default": "issuer_cik",
+ "type": "string"
+ },
+ "max_age_seconds": {
+ "const": 300,
+ "default": 300,
+ "type": "integer"
+ },
+ "point_in_time": {
+ "const": false,
+ "default": false,
+ "type": "boolean"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "enum": [
+ "disabled",
+ "missing",
+ "stale",
+ "future",
+ "invalid",
+ "read_failed"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": "missing"
+ },
+ "status": {
+ "default": "unavailable",
+ "enum": [
+ "available",
+ "unavailable"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Output schema / properties / results / items / properties / event_contextAdded value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "cik": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "cluster_buys": {
+ "default": [],
+ "items": {
+ "properties": {
+ "buyers": {
+ "type": "integer"
+ },
+ "evidence": {
+ "items": {
+ "properties": {
+ "accession_number": {
+ "type": "string"
+ },
+ "filed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "sec_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "accession_number",
+ "filed_at",
+ "sec_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "evidence_truncated": {
+ "type": "boolean"
+ },
+ "filings_count": {
+ "type": "integer"
+ },
+ "known_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "officer_director_buyers": {
+ "type": "integer"
+ },
+ "pattern": {
+ "const": "open_market",
+ "default": "open_market",
+ "type": "string"
+ },
+ "window_end": {
+ "format": "date",
+ "type": "string"
+ },
+ "window_start": {
+ "format": "date",
+ "type": "string"
+ }
+ },
+ "required": [
+ "window_start",
+ "window_end",
+ "known_at",
+ "buyers",
+ "officer_director_buyers",
+ "filings_count",
+ "evidence",
+ "evidence_truncated"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "cluster_buys_count": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "filings": {
+ "default": [],
+ "items": {
+ "properties": {
+ "accession_number": {
+ "type": "string"
+ },
+ "event_date": {
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "filed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "form": {
+ "enum": [
+ "8-K",
+ "6-K"
+ ],
+ "type": "string"
+ },
+ "items": {
+ "default": [],
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "kind": {
+ "anyOf": [
+ {
+ "const": "earnings_release",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "news_uid": {
+ "type": "string"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "period_label": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "primary_item": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "sec_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "form",
+ "accession_number",
+ "filed_at",
+ "observed_at",
+ "sec_url",
+ "news_uid"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "filings_count": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "enum": [
+ "non_sec_symbol",
+ "unknown_symbol",
+ "missing_cik",
+ "issuer_changed"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "status": {
+ "enum": [
+ "available",
+ "unsupported",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "ticker": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ticker",
+ "cik",
+ "status"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_ticker_news2 fields changedOutput schema / properties / items / items / properties / search_matchAdded 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
+}Output schema / properties / query_interpretationAdded value: +{
+ "anyOf": [
+ {
+ "description": "How ``alphai_news_search`` read a free-text ``query`` — the echo that makes\na resolver miss legible. Before it, a query read as the wrong company or\ndiscarded entirely came back indistinguishable from a hit\n(issues/2026-08-16-freetext-query-resolves-jane-street-to-janl.md).\n\n``mode``: ``resolved`` — at least one query word became a filter that is\napplied to the items; ``overridden`` — the query resolved, but explicit\n``tickers``/``category`` replaced every filter it produced; ``unresolved`` —\nno query word matched a ticker, company name or topic word, so the items\nare NOT matches for the query (``note`` says what they are instead).\n``ignored_terms`` lists the content words that matched nothing; stopwords\nare dropped silently. ``note`` is one or two plain sentences an agent can act\non, same role as ``ticker_note``.",
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "category_term": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "ignored_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "mode": {
+ "enum": [
+ "resolved",
+ "overridden",
+ "unresolved"
+ ],
+ "type": "string"
+ },
+ "note": {
+ "default": "",
+ "type": "string"
+ },
+ "search": {
+ "anyOf": [
+ {
+ "description": "How the text search read the query (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 2): ``strict`` = every term required; ``broadened`` = fewer strict\nmatches than the threshold, so any rare term plus at least two of the\nterms; ``no_match``; ``no_terms``. ``sort`` is ``published`` when every\nterm is a very common word (newest matches, not best). ``terms`` are the\nnormalized (stemmed) lexemes the index holds. ``matched`` counts the\nvisible matches inside the bounded candidate set, never a global total.",
+ "properties": {
+ "engine": {
+ "default": "postgres",
+ "enum": [
+ "postgres",
+ "meilisearch"
+ ],
+ "type": "string"
+ },
+ "matched": {
+ "default": 0,
+ "type": "integer"
+ },
+ "mode": {
+ "enum": [
+ "strict",
+ "broadened",
+ "no_match",
+ "no_terms"
+ ],
+ "type": "string"
+ },
+ "optional_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "required_terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sort": {
+ "enum": [
+ "relevance",
+ "published"
+ ],
+ "type": "string"
+ },
+ "terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "window_from": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ }
+ },
+ "required": [
+ "mode",
+ "sort"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "tickers": {
+ "items": {
+ "description": "One ticker a free-text ``query`` resolved to (docs/HYBRID_NEWS_SEARCH_PLAN.md\nstep 1). ``name`` is the issuer's registered name, so an agent can see that\n\"PMI\" was read as Picard Medical rather than the ISM purchasing-managers\nindex; ``term`` is the query word that produced it (share-class siblings\ninherit the seed word's term).",
+ "properties": {
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "term": {
+ "type": "string"
+ },
+ "ticker": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ticker",
+ "term"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "mode"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_trending1 field changedOutput schema / properties / result / items / properties / search_matchAdded 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
+}alphai_insider_clustersalphai_actionable_now1 field changedOutput schema / properties / result / items / properties / filingAdded 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
+}alphai_article1 field changedOutput schema / properties / filingAdded 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
+}alphai_insider_news1 field changedOutput schema / properties / items / items / properties / filingAdded 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
+}alphai_macro1 field changedOutput schema / properties / result / items / properties / filingAdded 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
+}alphai_news_search3 fields changedInput schema / properties / itemAdded value: +{
+ "anyOf": [
+ {
+ "pattern": "^\\d\\.\\d{2}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "8-K item code (e.g. '5.02', '8.01', '1.01'): keep only 8-K filings carrying it — any item of the filing. Implies source_type=['sec_form8k']; any other source_type is an error."
+}Input schema / properties / source_typeAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "description": "Ingestion source of a news row.",
+ "enum": [
+ "alpha_vantage",
+ "gdelt",
+ "sec_form4",
+ "sec_form8k",
+ "sec_form6k"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Restrict to these ingest sources (OR): gdelt = press coverage, sec_form4 = insider transactions, sec_form8k = 8-K current reports, sec_form6k = foreign issuers' 6-K earnings releases."
+}Output schema / properties / items / items / properties / filingAdded 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
+}alphai_pair_analysis3 fields changedOutput schema / properties / a_recent / items / properties / filingAdded 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
+}Output schema / properties / b_recent / items / properties / filingAdded 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
+}Output schema / properties / both / items / properties / filingAdded 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
+}alphai_ticker_news1 field changedOutput schema / properties / items / items / properties / filingAdded 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
+}alphai_trending1 field changedOutput schema / properties / result / items / properties / filingAdded 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
+}alphai_radaralphai_watchlist_briefalphai_earnings1 field changedOutput schema / properties / reports / items / descriptionPrevious value: -"One published AlphaAI earnings read, as served by ``alphai_earnings``."New value: +"One published AlphAI earnings read, as served by ``alphai_earnings``."alphai_actionable_now6 fields changedInput schema / properties / limit / descriptionPrevious value: -"Stories; capped at 10 Basic / 50 Pro."New value: +"Stories; capped at 20 Free/Basic, 50 Pro."Output schema / properties / result / items / properties / created_atAdded value: +{
+ "type": "string"
+}Output schema / properties / result / items / properties / earningsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / result / items / properties / insiderAdded 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
+}Output schema / properties / result / items / properties / source_typeAdded value: +{
+ "default": "",
+ "type": "string"
+}Output schema / properties / result / items / requiredPrevious 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"
+]alphai_alerts_list1 field changedOutput schema / properties / alerts / items / properties / noteAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_alerts_subscribe1 field changedOutput schema / properties / noteAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_article5 fields changedOutput schema / properties / created_atAdded value: +{
+ "type": "string"
+}Output schema / properties / earningsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / insiderAdded 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
+}Output schema / properties / source_typeAdded value: +{
+ "default": "",
+ "type": "string"
+}Output schema / requiredPrevious 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"
+]alphai_calendaralphai_earningsalphai_insider_news13 fields changedInput schema / properties / from_date / descriptionPrevious value: -"On/after this ISO time (UTC if naive)."New value: +"On/after this ISO time (UTC if naive); a bare date means that day's midnight."Input schema / properties / is_10b5_1Added value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Rule 10b5-1 filter, on the same field each item's insider block reports. Omit for every event; false = discretionary trades only (a 10b5-1 ladder was scheduled months earlier, so it carries no timing decision); true = plan events only. Event-level: a filing mixing plan and discretionary tranches counts as a plan event."
+}Input schema / properties / page_size / descriptionPrevious value: -"Items/page; capped at 10 Basic / 50 Pro."New value: +"Items/page; capped at 20 Free/Basic, 50 Pro."Input schema / properties / sortAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "published",
+ "ingested"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "published (default): newest first. ingested: delta polling — only Form 4 events added since your cursor, ascending; next_cursor is always returned (empty items = caught up, keep the cursor and poll later). Prefer this for watching insider activity: a filing arrives days after its transaction date, so it can land below the newest page of a publish-ordered feed. A cursor only works with the sort mode that issued it."
+}Input schema / properties / to_date / descriptionPrevious value: -"On/before this ISO time (UTC if naive)."New value: +"On/before this ISO time (UTC if naive); a bare date covers that whole day. Bounds when the filing reached the feed, not the insider's transaction_date."Output schema / properties / delistedAdded value: +{
+ "default": false,
+ "type": "boolean"
+}Output schema / properties / items / items / properties / created_atAdded value: +{
+ "type": "string"
+}Output schema / properties / items / items / properties / earningsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / items / items / properties / insiderAdded 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
+}Output schema / properties / items / items / properties / source_typeAdded value: +{
+ "default": "",
+ "type": "string"
+}Output schema / properties / items / items / requiredPrevious 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"
+]Output schema / properties / renamed_toAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / ticker_noteAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_macroalphai_news_search12 fields changedInput schema / properties / from_date / descriptionPrevious value: -"News on/after this ISO time (UTC if naive)."New value: +"News on/after this ISO time (UTC if naive); a bare date means that day's midnight."Input schema / properties / page_size / descriptionPrevious value: -"Items/page; capped at 10 Basic / 50 Pro."New value: +"Items/page; capped at 20 Free/Basic, 50 Pro."Input schema / properties / sortAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "published",
+ "ingested"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "published (default): newest first, next_cursor pages into older history. ingested: delta polling — rows in the order they became available, ascending; next_cursor is always returned (empty items = caught up, keep the cursor and poll later); time_published is not monotonic within a page. A cursor only works with the sort mode that issued it."
+}Input schema / properties / to_date / descriptionPrevious value: -"News on/before this ISO time (UTC if naive)."New value: +"News on/before this ISO time (UTC if naive). A bare date (2026-06-01) covers that WHOLE day, so from_date=to_date=<day> returns the day — same reading as REST /api/news/."Output schema / properties / delistedAdded value: +{
+ "default": false,
+ "type": "boolean"
+}Output schema / properties / items / items / properties / created_atAdded value: +{
+ "type": "string"
+}Output schema / properties / items / items / properties / earningsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / items / items / properties / insiderAdded 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
+}Output schema / properties / items / items / properties / source_typeAdded value: +{
+ "default": "",
+ "type": "string"
+}Output schema / properties / items / items / requiredPrevious 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"
+]Output schema / properties / renamed_toAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / ticker_noteAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_pair_analysis15 fields changedOutput schema / properties / a_recent / items / properties / created_atAdded value: +{
+ "type": "string"
+}Output schema / properties / a_recent / items / properties / earningsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / a_recent / items / properties / insiderAdded 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
+}Output schema / properties / a_recent / items / properties / source_typeAdded value: +{
+ "default": "",
+ "type": "string"
+}Output schema / properties / a_recent / items / requiredPrevious 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"
+]Output schema / properties / b_recent / items / properties / created_atAdded value: +{
+ "type": "string"
+}Output schema / properties / b_recent / items / properties / earningsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / b_recent / items / properties / insiderAdded 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
+}Output schema / properties / b_recent / items / properties / source_typeAdded value: +{
+ "default": "",
+ "type": "string"
+}Output schema / properties / b_recent / items / requiredPrevious 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"
+]Output schema / properties / both / items / properties / created_atAdded value: +{
+ "type": "string"
+}Output schema / properties / both / items / properties / earningsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / both / items / properties / insiderAdded 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
+}Output schema / properties / both / items / properties / source_typeAdded value: +{
+ "default": "",
+ "type": "string"
+}Output schema / properties / both / items / requiredPrevious 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"
+]alphai_ticker_news11 fields changedInput schema / properties / min_relevanceAdded value: +{
+ "default": 4,
+ "description": "Minimum AI relevance score, 1-10.",
+ "maximum": 10,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / page_size / descriptionPrevious value: -"Items/page; capped at 10 Basic / 50 Pro."New value: +"Items/page; capped at 20 Free/Basic, 50 Pro."Input schema / properties / sortAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "published",
+ "ingested"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "published (default): newest first. ingested: delta polling — only rows added since your cursor, ascending; next_cursor is always returned (empty items = caught up, keep the cursor and poll later). A cursor only works with the sort mode that issued it."
+}Output schema / properties / delistedAdded value: +{
+ "default": false,
+ "type": "boolean"
+}Output schema / properties / items / items / properties / created_atAdded value: +{
+ "type": "string"
+}Output schema / properties / items / items / properties / earningsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / items / items / properties / insiderAdded 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
+}Output schema / properties / items / items / properties / source_typeAdded value: +{
+ "default": "",
+ "type": "string"
+}Output schema / properties / items / items / requiredPrevious 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"
+]Output schema / properties / renamed_toAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / ticker_noteAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_tickers1 field changedOutput schema / properties / items / items / properties / next_report_dateAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}alphai_trending6 fields changedInput schema / properties / limit / descriptionPrevious value: -"Stories; capped at 10 Basic / 50 Pro."New value: +"Stories; capped at 20 Free/Basic, 50 Pro."Output schema / properties / result / items / properties / created_atAdded value: +{
+ "type": "string"
+}Output schema / properties / result / items / properties / earningsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / result / items / properties / insiderAdded 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
+}Output schema / properties / result / items / properties / source_typeAdded value: +{
+ "default": "",
+ "type": "string"
+}Output schema / properties / result / items / requiredPrevious 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"
+]alphai_actionable_now1 field changedInput schema / properties / limit / descriptionPrevious value: -"Stories. 10 Basic / 50 Pro (tools.bulk)."New value: +"Stories; capped at 10 Basic / 50 Pro."alphai_insider_news2 fields changedInput schema / properties / limitAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Alias for page_size."
+}Input schema / properties / page_size / descriptionPrevious value: -"Items/page. 10 Basic / 50 Pro (tools.bulk)."New value: +"Items/page; capped at 10 Basic / 50 Pro."alphai_news_search4 fields changedInput schema / properties / limitAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Alias for page_size."
+}Input schema / properties / page_size / descriptionPrevious value: -"Items/page. 10 Basic / 50 Pro (tools.bulk)."New value: +"Items/page; capped at 10 Basic / 50 Pro."Input schema / properties / qAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Alias for query."
+}Input schema / properties / queryAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Free-text query (company names / tickers / topic words) resolved to ticker + category filters."
+}alphai_ticker_news2 fields changedInput schema / properties / limitAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Alias for page_size."
+}Input schema / properties / page_size / descriptionPrevious value: -"Items/page. 10 Basic / 50 Pro (tools.bulk)."New value: +"Items/page; capped at 10 Basic / 50 Pro."alphai_trending1 field changedInput schema / properties / limit / descriptionPrevious value: -"Stories. 10 Basic / 50 Pro (tools.bulk)."New value: +"Stories; capped at 10 Basic / 50 Pro."alphai_pair_analysis1 field changedOutput schema / descriptionPrevious value: -"Read-across between two tickers: news naming BOTH (where the cross-ticker\nsignal lives), plus each ticker's own recent news for context."New value: +"Read-across between two tickers: news naming BOTH (where the cross-ticker\nsignal lives), plus each ticker's own recent news for context.\n\n``both`` items carry the full analysis (the read-across). ``a_recent`` /\n``b_recent`` are condensed — identity + summary + the scalar trading signals\n(actionability / novelty / sentiment), with the prose analysis dropped; fetch\n``alphai_article(uid)`` for the full write-up of a recent item."alphai_ticker_news1 field changedInput schema / properties / include_insider / descriptionPrevious value: -"Include insider/13F ownership news; default true."New value: +"Include SEC Form 4 insider news; default true."fetchsearchalphai_news_search1 field changedInput schema / properties / qRemoved value: -{
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Free-text query; tokens AND-matched in title/summary."
-}alphai_actionable_nowalphai_alerts_listalphai_alerts_subscribealphai_alerts_unsubscribealphai_articlealphai_insider_newsalphai_news_searchalphai_pair_analysisalphai_ticker_newsalphai_tickersalphai_trendingReal-time financial news for AI agents: search by ticker and source, with sentiment and entities.
US stock market data for AI agents: SEC filings, financials, insider trades, 13F, options, macro.
Stock market data for AI agents: real-time quotes, financials, options, SEC filings and news.
Real-time news with bias scoring, live market data, and AI-powered options pricing
Add one secure layer between your agents and this server.
