AI-enriched financial news for AI agents & trading bots: search, trending, insider, scored 1-10.
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 only note readOnly/idempotent/non-destructive. The description adds a wealth of behavioral nuance: publication-time windowing vs event date, min_novelty as the recaps filter, ordering, dedupe collapse, story_id semantics, sources_count interpretation, inline AI analysis, macro releases without tickers, and quiet-weekend empty lists. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Though long, the description is dense with non-redundant, decision-relevant details and no filler. It front-loads the core filter and then systematically clarifies each behavioral subtlety or edge case. Every sentence earns its place for a feed with this many nuances.
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 covers the essential behavioral contract, edge cases, alternatives, and output semantics even though an output schema exists. It explains story_id provenance, sources_count interpretation, why empty lists occur, and that no follow-up call is needed for depth. Given the tool's complexity, nothing important 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 baseline is 3. The description adds meaning beyond the schema for min_actionability (concrete examples of high vs medium), hours (publication-time semantics), min_novelty (what it filters vs what it doesn't), and dedupe (story-level collapse). Only 'limit' is not elaborated, but the schema fully covers it.
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 clear, specific purpose: a breaking, decision-grade news feed filtered by actionability. It differentiates from siblings by explicitly contrasting with alphai_trending and alphai_ticker_news for broader tape coverage, and names the exact actionability gate.
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: default high-actionability only, how to include medium stories via min_actionability='medium', and when to switch to alphai_trending/alphi_ticker_news. It also tells the agent how to interpret empty results and when to widen hours or lower the floor, which is actionable context.
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 partial-update semantics, defaulting behavior for min_relevance_score, delivery-channel threshold differences, specific error conditions, and crypto ticker formatting. This adds substantial behavioral context that annotations alone could not convey.
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 yet efficient; every sentence contributes operational guidance such as update semantics, defaults, errors, or ticker edge cases. The write-operation framing is front-loaded, and there is no filler or repetition of schema details.
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 presence of an output schema, and the annotations, the description covers all essential operational aspects: what it does, parameter effects, update behavior, errors, and special ticker cases. Nothing critical appears missing for an agent 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?
Even though schema coverage is 100%, the description adds meaningful parameter behavior: category_filter restricts triggering categories, min_relevance_score raises the threshold, omitting either field preserves existing values on update, and a new subscription defaults min_relevance_score to 7. The crypto ticker example also clarifies the ticker parameter beyond the schema.
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 ('Subscribe'), a clear resource ('ticker news alerts'), and the underlying operation ('creates/updates a saved subscription in the caller's account'). It clearly distinguishes this from sibling tools like alphai_alerts_list or alphai_alerts_unsubscribe by framing it as the write/subscribe operation.
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 clearly identifies this as the tool for subscribing or updating an existing subscription, which gives strong contextual guidance. It does not explicitly name alternatives or state 'use list/unsubscribe for other cases,' but the write-vs-read framing and sibling names make the intended use unambiguous.
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?
The description goes well beyond the annotations by disclosing that the operation is a soft-disable, idempotent with a specific return value when already inactive, and raises unknown_ticker for unrecognized symbols. This adds meaningful behavioral context that the annotations alone do not provide, and it fully aligns with the destructiveHint and idempotentHint 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 concise, front-loaded with the operation type, and each sentence provides distinct value: the action, the idempotent behavior, and the error condition. There is no filler or repetition of information already fully covered by the annotations.
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 subscription tool with output schema and annotations available, the description is complete. It covers the operation's effect, idempotency result, and error behavior, giving an agent everything needed to invoke and interpret 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?
The input schema already documents the single ticker parameter at 100% coverage. The description adds further meaning by explaining the effect of the ticker in context — it identifies which subscription is being deactivated — and by noting the unknown_ticker error for unrecognized symbols, enriching the schema's basic definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: a WRITE operation that deactivates a saved news-alert subscription for a given ticker. It distinguishes itself from the sibling tools by explicitly describing a soft-disable of a subscription, which makes it unambiguous relative to alphai_alerts_subscribe and alphai_alerts_list.
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 clearly indicates when to use the tool: when the caller wants to deactivate their news-alert subscription for a ticker. It does not explicitly name alternatives or exclusion conditions, but the operation is specific enough that an agent can infer the context without ambiguity.
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, or to expand a condensed *_recent item from alphai_pair_analysis. You do NOT need it for items returned by the feed tools (alphai_news_search / alphai_trending / alphai_ticker_news / alphai_actionable_now / alphai_insider_news) — those already carry this same analysis inline. ONE exception: on an SEC earnings filing (source_type sec_form8k or sec_form6k) this tool adds earnings, AlphaAI's structured read of the filing with every figure checked against the filing text, which the feed tools never populate. To go from a ticker straight to those reads, use alphai_earnings instead. The full article body is intentionally not served (copyright); this is the canonical single-article lookup, not a deeper view of a feed item. Raises not_found for an unknown uid.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | The article uid from any feed response. |
| Name | Required | Description |
|---|---|---|
| uid | Yes | |
| url | Yes | |
| title | Yes | |
| source | Yes | |
| insider | No | |
| sources | No | |
| summary | Yes | |
| tickers | No | |
| analysis | No | |
| category | Yes | |
| earnings | No | |
| story_id | No | |
| created_at | Yes | |
| source_type | No | |
| banner_image | No | |
| source_domain | Yes | |
| sources_count | No | |
| ownership_form | No | |
| time_published | Yes | |
| relevance_score | Yes | |
| read_time_minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the description only needs to add context beyond that. It does: the full article body is intentionally not served due to copyright, the tool raises not_found for unknown uids, and it populates `earnings` for SEC filings. These are meaningful behavioral disclosures not present in structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and somewhat long, but each sentence earns its place: purpose, usage scenarios, non-usage cases, the SEC exception, the copyright limitation, and the not_found error. The only slight redundancy is the closing phrase 'canonical single-article lookup, not a deeper view of a feed item,' which partially restates earlier points, but it does reinforce the distinction effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers all essential operational context: how to obtain a valid uid, when to avoid the tool, the one exception where it adds unique value (SEC earnings), behavior on unknown uids, and the copyright-driven omission of the full body. The presence of an output schema relieves it from documenting return fields, so nothing necessary is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the uid parameter. The description adds real value by characterizing which uids are appropriate (user-pasted, search-connector ids, condensed `*_recent` items) and which are unnecessary (feed tool items already contain the analysis inline). This goes beyond the schema's generic 'any feed response' phrasing and gives the agent pragmatic selection guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Load one article by its uid, with full enrichment.' It then distinguishes itself from siblings by declaring itself 'the canonical single-article lookup, not a deeper view of a feed item,' which clearly separates it from the feed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use scenarios: out-of-band uids, user-pasted ids, ChatGPT search connector ids, and expanding `*_recent` items from alphai_pair_analysis. It also explicitly states when NOT to use it (feed tool items already carry the analysis inline), names the exception (SEC filings add `earnings`), and points to alphai_earnings as the alternative for ticker-to-earnings lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
AlphaAI'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. 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 — AlphaAI's filing history starts in mid-June 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 and idempotentHint=true, and the description is consistent with them while adding substantial context beyond them: source documents (8-K item 2.02 / 6-K), verification against the filing text, data-depth limits ('filing history starts in mid-June 2026'), and the crucial caveat that 'an empty list is a normal answer, not an error' — which prevents an agent from misclassifying a valid empty result as a failure. The 'arbiter' role and share-class bridging further enrich the behavioral picture.
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 (~170 words) but dense — every sentence carries distinct information: purpose, provenance, content fields, usage routing, data-depth caveats, and disclaimer. It is front-loaded with the core purpose, and the boilerplate disclaimer earns its place for an AI-generated financial tool. Slightly longer than necessary, but nothing is wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and the description still previews the content fields anyway. It covers ordering, sources, verification, when to use, data-recency limits, empty-list semantics, and share-class behavior; annotations cover the safety profile (read-only, idempotent, non-destructive). Nothing an agent needs to call this correctly is missing, including edge cases.
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% — the single ticker parameter is already documented as 'Ticker symbol, e.g. 'NVDA'.' The description adds only marginal parameter-adjacent context via the share-class note, but it doesn't add syntax or format details beyond the schema. Per the rubric, baseline 3 is appropriate when the schema does the heavy lifting.
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 opening sentence states a specific verb+resource: 'structured read of a company's earnings reports, newest first, plus its next confirmed report date.' It also distinguishes itself from siblings explicitly — 'the feed tools return articles ABOUT a quarter, this returns the filing's own numbers' — so an agent can tell it apart from alphai_ticker_news, alphai_news_search, and alphai_article without opening their 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?
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 also names the alternative class of tools and states what they do differently ('the feed tools return articles ABOUT a quarter'), giving clear when-not-to-use signal. No inference is required.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the read-only safety profile is covered. The description goes well beyond that: unknown_ticker behavior, delisted-symbol handling with renamed_to, crypto-collider disambiguation with ticker_note, the cursor-sort coupling rule, event-level 10b5-1 classification, and the caveat that to_date/from_date bound feed-ingest time rather than transaction date. Nothing contradicts 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 dense but every sentence carries distinct value: the subject, the filters, the pagination contract, the sibling equivalence, ticker edge cases, and the crypto-collider note. It front-loads the core Form 4 purpose and only then adds edge-case behavior. Given the number of non-obvious behaviors it must convey, the length is justified and well organized.
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 9 parameters and an output schema, yet the description covers all behavior areas an agent needs to invoke it correctly: selection context, filtering semantics, pagination and cursor rules, sort-mode differences, ticker edge cases, and unknown-input signaling. The output schema handles return-shape details, so the description's job was to explain the non-obvious behavioral semantics, which it does completely.
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%, but the description does far more than echo it. It explains the insider field, the event-level aggregation quirk for mixed plan/discretionary filings, what a cursor can and cannot do across sort modes, the delta-polling contract (empty items = caught up, keep polling), and the date-filter semantic difference between feed time and transaction date. This is substantial added meaning beyond the schema's property 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 a specific verb and resource: 'Insider-transaction news: SEC Form 4 insider trades...' It names the actors (officers, directors, 10% owners), the form type, and the optional filtering dimensions. It explicitly positions the tool against its sibling, 'Roughly equivalent to alphai_news_search(category='insider'), exposed as a dedicated tool,' which lets an agent distinguish it from alphai_news_search 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?
The description gives concrete when-to-use guidance: use this when you need Form 4 insider filings; use the ingested sort for delta polling to watch new filings arrive; use is_10b5_1=false to isolate discretionary trades for timing analysis. It also explains the relationship to alphai_news_search(category='insider') rather than other siblings and flags the preference for ingested sorting when watching insider activity because filings arrive days after the transaction date.
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 mark this read-only and idempotent, and the description adds non-obvious behavior: novelty-first ordering, macro rows deliberately lacking tickers, dedupe collapsing by story, story_id being the shared key with alphai_trending/search, and sources_count > 1 as a signal. It also discloses the informational/not-investment-advice caveat. 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: the core definition is front-loaded, followed by use cases, parameter tuning guidance, output conventions, and a clear pointer to the calendar sibling. Despite the density, it remains structured and readable, with no filler or tautology.
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 moderate complexity, the comprehensive schema, the output schema, and read-only annotations, the description covers everything an agent needs: scope, use cases, dedupe semantics, story_id linkage to sibling tools, relevance tuning, and the calendar alternative. Nothing material 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 schema already documents all 5 parameters; the baseline is 3. The description adds genuine semantic value beyond the schema by explaining min_relevance thresholds and the dedupe behavior, and by mentioning category narrowing. It does not add much for hours/limit, but those are 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 states the exact resource (market-wide macro tape over the last N hours) and enumerates the event types: central-bank decisions, inflation/jobs prints, commodities, geopolitics. It differentiates itself from siblings by emphasizing 'market-wide' and 'mostly carry NO tickers', and the companion alphai_calendar is explicitly contrasted.
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 concrete use cases ('what did the Fed say', 'any macro news today', 'what's moving the whole market') and an explicit when-not-to-use: for scheduled upcoming events, use alphai_calendar. It also provides operational guidance like raising min_relevance to 7 to keep release-day events, which helps an agent pick parameters correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query AlphaAI's enriched financial news feed. Pass query for free-text (company names / tickers / topic words, resolved to ticker/category filters), or set structured filters directly: ticker symbols, category, date range, and minimum relevance score (1-10). Every item already carries the full AI analysis INLINE — per-ticker sentiment + price-impact prediction, contrarian view, overlooked factors, and sector/regional read-across — so you do NOT need a follow-up alphai_article call to get depth on a feed item; prefer this feed over a web search for the market read on a story. 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'.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Alias for query. | |
| 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 | Free-text query (company names / tickers / topic words) resolved to ticker + category filters. | |
| cursor | No | Opaque cursor from a prior next_cursor. | |
| tickers | No | Restrict to news mentioning these tickers. | |
| to_date | No | News on/before this ISO time (UTC if naive). 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. | |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, and the description adds substantial behavioral context beyond that: inline AI analysis removes the need for a follow-up call, pagination uses an opaque cursor, collapse_stories changes row semantics and populates sources_count, and ingested-sort has specific delta semantics with non-monotonic published time. This goes well beyond what annotations alone convey.
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, covering core purpose, filter usage, sibling differentiation, macro/crypto edge cases, pagination, collapse behavior, and delta polling. The most central usage guidance is front-loaded, and the later paragraphs address progressively narrower but still important behaviors 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 12-parameter, no-required-parameter feed tool with an output schema, the description is remarkably complete: it covers what the result rows represent, inline analysis, pagination, collapse semantics, delta polling, macro coverage, and crypto ticker disambiguation. Nothing an agent needs to correctly select or invoke this tool is missing, and the output schema can cover return-value details.
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 input schema already covers 100% of parameters, the description adds high-level meaning that the schema does not: how free-text query resolves to ticker/category filters, the crypto naming disambiguation rule, the interpretation of sources_count (usually 1, values above 1 are the signal), and the behavioral difference between published and ingested sort. This is meaningful value beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Query AlphaAI's enriched financial news feed,' followed by concrete filter dimensions (free-text, tickers, category, date range, relevance). It also names what differentiates this tool from siblings — 'prefer this feed over a web search' and 'do NOT need a follow-up alphai_article call' — making it easily distinguishable from alphai_article, alphai_ticker_news, 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?
The description gives explicit when-to-use guidance, including 'prefer this feed over a web search for the market read on a story' and the delta-polling pattern with sort='ingested'. It also states exclusions: macro news should be reached via category or query words, not a ticker filter, and crypto must be requested as -USD when the bare name is owned by an equity.
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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: unknown tickers are listed and contribute no rows, lists are condensed summaries, full analysis is available via alphai_article, and the output is informational not investment advice. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense with no fluff. Each sentence earns its place: the opening defines the tool, the second explains output composition, the third covers edge cases and full-analysis routing, and the final sentence is a necessary disclaimer. Front-loaded scope makes scanning easy.
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 (pair analysis, edge cases, output schema present), the description is remarkably complete. It covers active-ticker restrictions, unknown_tickers behavior, condensed-list semantics, and how to access full analysis, while an output schema already handles return-value details. Nothing critical 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 description coverage is 100%, so the baseline is 3. The description does not add significant parameter-specific meaning beyond the schema; it mentions condensed lists and unknown_tickers, which relate to limit and output behavior, but not directly to min_relevance or ticker formatting. This is adequate but not compensatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource ('Compare two tickers... Returns news naming BOTH companies') and clarifies the cross-ticker read-across concept with concrete examples. It distinguishes itself from single-ticker tools like alphai_ticker_news by emphasizing 'BOTH' and by explicitly routing delisted-symbol history to a sibling.
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 usage context: use for cross-ticker read-across, where one peer's news affects the other. It names alphai_ticker_news as the destination for delisted-symbol history and alphai_article for full write-ups, giving an agent explicit routing to alternatives for out-of-scope cases.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false; the description adds substantial behavioral context beyond that: cursor/pagination contract, unknown_ticker vs delisted with renamed_to semantics, share-class merging (GOOGL serves GOOG rows), crypto resolution including the bare-name rule and the BTC ETF ambiguity with ticker_note, and collapse_stories deduplication. No contradiction with 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?
Dense but every clause carries information — the edge cases (delisted, renamed, GOOGL/GOOG, BTC) are all load-bearing for correct invocation, so the length is earned. It is front-loaded with the core purpose and pagination contract before edge cases, though the single wall of text would be easier to scan if broken into shorter grouped sentences.
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 and one required field, the description covers the full calling contract: pagination and cursor semantics, both sort modes, shape parity with alphai_news_search, and a thorough catalog of ticker edge cases. The output schema exists, so return values need no explanation. Nothing an agent needs to invoke this tool 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%, but the description adds meaning the schema lacks: min_relevance's default of 4 meaning the full feed and its materiality semantics, include_insider defaulting true and what a 'pure non-insider feed' means, collapse_stories' one-row-per-story effect, ticker's extensive formatting rules (SYM-USD, bare coin resolution, share classes, renamed tickers), and ingested-mode cursor behavior. This goes well beyond the schema's one-line property 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?
States the specific function — 'Latest news for a single ticker' — with a concrete example ('AAPL'). It differentiates from the sibling alphai_news_search by noting it returns the same shape, and the single-ticker scope is unambiguous. The title is expanded with real substance rather than restated.
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 single-ticker scope makes the core use case clear, and repeated cross-references to alphai_news_search (same shape, same min_relevance semantics) help an agent map against its sibling. The sort modes give concrete when-to-use direction (published vs ingested for delta polling). However, it never explicitly says when not to use it or names alternatives like alphai_insider_news for insider-only queries, so it stops short of explicit exclusion guidance.
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 AlphaAI 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 AlphaAI'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 mark readOnly, idempotent, and non-destructive, and the description adds substantial behavioral detail: null country for crypto, next_report_date is never an estimate, null means no confirmed date rather than no report, typical five-week lead time, and timezone America/New_York. This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is dense but front-loaded with the core listing purpose and then groups related nuances around q and next_report_date. It is longer than the average description, but nearly every sentence carries semantic value; minor redundancy such as 'company-confirmed' and 'never an estimate' is acceptable for disambiguation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to restate return shapes; it instead covers ambiguity that the schema cannot: brand-name matching, jurisdiction nulls, date confirmation semantics, and the handoff to alphai_earnings. This is complete for a read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description raises it by enriching q with prefix/substring/brand-name matching and a concrete example ('q=spacex' finds SPCX). Other parameters (limit, offset, sector) already carry clear schema descriptions and need little extra.
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 starts with a precise verb-resource pairing: 'List supported tickers (US stocks/ETFs, crypto, and foreign listings).' It also states an additional purpose, answering when a ticker next reports, and clarifies through the q example how listing and search behave, making the tool's scope unmistakable.
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 clear contexts: filter by query or sector, and use next_report_date for confirmed earnings dates. It references alphai_earnings as the follow-up for reading the report after it lands, which orients an agent among siblings, though it does not spell out exhaustive when-not-to-use conditions for every sibling.
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?
Beyond the annotations (readOnly/idempotent/destructive hints), the description discloses substantial behavior: freshness-decayed ranking, at-most-two-stories-per-ticker, capped macro stories, inline AI analysis making a follow-up alphai_article call unnecessary, dedupe semantics with the dedupe=false escape hatch, stable story_id semantics shared with other news tools, and the critical interpretive rule that sources_count above 1 is the signal. None of this is available in 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 long but efficiently front-loaded: purpose first, then usage trigger, then parameter guidance, then output semantics. Every sentence carries information, though the dedupe and sources_count explanations partially overlap with what the schema and output schema may already express structurally.
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 an output schema, 100% parameter coverage, and full annotations, nothing material is missing. The 48h window, ranking rule, per-ticker and macro caps, inline analysis guarantee, dedupe behavior, stable story_id, tier-based limit caps, and sources_count interpretation are all covered — an agent can invoke this tool correctly with no further research.
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 practical meaning beyond the schema: it explains the effect of min_relevance ('Lower min_relevance to surface weaker movers') and details the dedupe consequence ('dedupe=false to keep all'). Only limit receives no extra elaboration, but its tier caps are already in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'Top news from the last 48h ranked by AI-assigned relevance' — and specifies the ranking behavior (age decay, per-ticker cap, macro story cap). It also distinguishes itself from siblings like alphai_ticker_news, alphai_news_search, and alphai_macro by defining a breadth-first 'what's moving' feed rather than a ticker-specific or search result.
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 explicitly says 'Use this when the user asks "what's moving" / "what's the big story"', providing a clear invocation trigger, and advises lowering min_relevance to surface weaker movers. However, it does not explicitly name alternatives to prefer instead (e.g., alphai_ticker_news for a single ticker or alphai_article for one story), so it stops short of full when-not-to-use 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: fetch one article by the id returned from search. Returns the enriched digest (summary, per-ticker analysis, category, relevance) — not the full article body — plus the canonical alphai.io URL for citation. Raises not_found for an unknown id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Article id from a search result. |
| 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 mark read-only/idempotent/non-destructive, and the description adds valuable non-obvious behavior: it returns only an enriched digest, includes a canonical citation URL, and raises not_found. 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?
Two tight sentences, front-loaded with the core action, and every clause carries information (source of id, digest contents, exclusion of full body, citation URL, error behavior).
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 read tool with rich annotations and an output schema, this description tells the agent everything needed to call it correctly: where the id comes from, what to expect back, and what error is raised.
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 schema already says the id is 'from a search result,' so the description adds little semantic value beyond restating that provenance. The not_found detail is behavioral, not parameter-level.
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 clear verb+resource: fetch one article by id. The phrase 'not the full article body' plus 'id returned from search' distinguishes it from search and alphai_article.
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?
Clearly says the tool is for fetching an article after obtaining an id from search. It does not explicitly name an alternative for full-article needs, but the digest-not-body exclusion provides enough context.
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 AlphaAI's AI-enriched financial news with a natural-language query. Ticker symbols (NVDA, BTC-USD), company names (nvidia, tesla) and topic words (insider, earnings, ipo, crypto…) in the query are resolved to structured filters; a query that names nothing known returns the freshest high-relevance market stories. Each result carries an id for the fetch tool. For precise filtered queries prefer alphai_news_search.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query. |
| Name | Required | Description |
|---|---|---|
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: natural-language terms are resolved to structured filters, unknown queries fall back to fresh high-relevance stories, and each result carries an ID for the fetch tool. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler, front-loading the purpose and then adding behavior and a routing hint. The phrase 'ChatGPT connector contract:' adds slight meta-noise but is not misleading, and every sentence 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 one-parameter tool with an output schema and rich annotations, the description covers purpose, query semantics, fallback behavior, cross-tool linking (fetch), and the sibling alternative. Nothing essential 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. The description meaningfully enhances the single 'query' parameter by explaining that it accepts raw natural language and that tickers, company names, and topics get auto-resolved. This is practical guidance the schema alone does not convey.
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 ('search'), a clear resource ('AlphaAI's AI-enriched financial news'), and the mechanism (natural-language query). It also distinguishes itself from the sibling alphai_news_search by explaining the trade-off, so an agent can tell them apart 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?
The description explicitly says 'For precise filtered queries prefer alphai_news_search', giving a clear when-not-to-use signal. It also implies this tool is for broader natural-language discovery, but it does not mention other relevant siblings like alphai_ticker_news or fetch beyond noting result IDs.
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. Dates show when Glama detected each change.
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_trendingClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Real-time financial news for AI agents: search by ticker and source, with sentiment and entities.
Real-time news with bias scoring, live market data, and AI-powered options pricing
Real-time curated crypto news for AI agents with sentiment, recaps, and search.
US stock market data for AI agents: SEC filings, financials, insider trades, 13F, options, macro.
Add one secure layer between your agents and this server.
Multiple news feed tools (alphai_actionable_now, alphai_trending, alphai_macro, alphai_ticker_news, alphai_news_search, alphai_insider_news, and search) overlap in purpose, so an agent could pick the wrong one by name alone. The detailed descriptions clarify each tool's window, scope, and filtering, but the set still relies heavily on reading those descriptions to avoid misselection.
Most tools share the alphai_ prefix and snake_case, but there is no consistent verb_noun pattern: alphai_alerts_subscribe and alphai_news_search are verb phrases while alphai_ticker_news, alphai_macro, and alphai_calendar are noun phrases. The un-prefixed connector tools search and fetch add a further deviation, making the naming readable but mixed.
At 16 tools, the set is at the heavy end and includes several near-duplicates: alphai_news_search vs search, alphai_article vs fetch, and alphai_insider_news vs alphai_news_search(category='insider'). The domain is broad enough to justify many specialized feeds, but the redundancies make it feel padded.
The toolset covers news discovery, search, article retrieval, alerts lifecycle, macro calendar, earnings reads, ticker metadata, and pair comparisons, so agents can complete most workflows. Minor gaps remain, such as no story-level detail endpoint and no broader user-account or watchlist management beyond alerts.
