Realtime financial context for AI agents: what changed, who is affected, and what to watch next. One suite covering news, events, guidance, filing changes, sentiment, stakeholders, and alerts. Information-efficient responses with evidence for every result. First-class point-in-time safety for backtests. Pairs well with web search and a market-data API. All data is our own.
Scored across 19 tools
The alert lifecycle tools (create/activate/deactivate/delete/get) are cleanly separated, and the research tools mostly carve out distinct roles (search vs. retrieve-by-id vs. retrieve-by-event). The only soft overlap is in the guidance trio (list_guidance, list_guidance_outcomes, guidance_bias), which are related views of the same data and could be momentarily confused, and market_signal vs. list_wire both surface wire aggregates.
The set overwhelmingly follows a verb_noun convention (create_alert, list_guidance, retrieve_entity, search_events, screen_stocks). The exceptions are two noun-only names, guidance_bias and market_signal, which are minor deviations from an otherwise predictable pattern.
At 19 tools the surface spans two fairly different areas (alert administration and market/wire research), which pushes it into the heavy range. Every tool has a plausible purpose, but the set is large enough that an agent must scan groups before acting.
Alerts have full lifecycle coverage including pause/resume and delete, and the research side covers search, retrieval, storylines, guidance, and screening. Minor gaps remain: no update/edit tool for alert criteria and no direct retrieve_event by ID (only search_events and retrieve_event_developments), which agents must work around.
Activate a paused alert.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds the state precondition (target must be paused), which the annotations don't convey, but it doesn't say whether activation is reversible, what side effects it triggers (e.g., resuming notifications), or how it behaves on an already-active alert.
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?
One short, front-loaded sentence with no filler or redundancy. It is efficient, though the brevity borders on under-specification rather than disciplined concision.
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 state-mutating tool with no output schema and zero parameter documentation, the description does the bare minimum. An agent still cannot tell what activation actually changes, what is returned, how failures (alert not paused, unknown ID) are surfaced, or whether the effect is reversible.
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 0% for the single required parameter alert_id, so the description is the only place meaning could be added — and it says nothing about the ID's format, where to obtain it, or whether it comes from get_alerts. The parameter name is largely self-explanatory, which keeps this from being a 1, but the low coverage is not compensated for.
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?
"Activate a paused alert" states a specific verb (activate) applied to a specific resource (alert), and the word "paused" implicitly contrasts with the sibling deactivate_alert. It is clear what the tool does, though it never names the opposite tool or otherwise explicitly differentiates itself from the alert siblings.
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?
"Paused" implies a precondition — the alert must already be in a paused state for this to be the right call — which is useful implied guidance. There is no explicit when-to-use/when-not-to-use statement and no pointer to deactivate_alert, create_alert, or delete_alert as alternatives for other state transitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a realtime alert that delivers matching updates to email, Telegram, or a webhook.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Unique label; auto-generated if omitted | |
| detail | No | essential:minimal; standard:citable; full:all. | full |
| receivers | Yes | 1-2 unique targets. | |
| conditions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/open-world profile is covered. The description adds the push-delivery semantics, but it does not say whether the alert is active immediately on creation (a meaningful gap given the activate/deactivate siblings) or what limits apply.
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?
One short, front-loaded sentence with no filler, so nothing is wasteful. However, for a tool with this much conditional structure the terseness reads as under-specification rather than efficiency.
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 schema exposes five mutually exclusive condition sources (wire, developments, guidance, guidance_outcomes, changes) with dozens of filter fields, yet the description never mentions them or hints which source an agent should pick. For a complex nested create tool with no output schema, this leaves the agent to reverse-engineer the core matching model from the schema alone.
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 75%, so the schema largely documents name, detail, receivers and the five condition variants on its own. The description adds no parameter-level meaning beyond restating the receiver enum values, which the schema already constrains.
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?
Specific verb ('Create') plus resource ('realtime alert') and it names the delivery channels (email, Telegram, webhook), so the operation is unambiguous. It does not explicitly contrast itself with the activate/deactivate/delete alert siblings, so differentiation is only implicit through the verb.
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 word 'realtime' implies when to use it (push notifications on matching updates), but there is no explicit when-not guidance and no mention of the lifecycle relationship to activate_alert/deactivate_alert. Prerequisites such as starting the Telegram bot first live only in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause an active alert.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation, but the description adds no behavioral context of its own. It does not say whether pausing is reversible, whether the pause has a duration, whether in-flight deliveries are stopped, or whether the alert's history is preserved.
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 single short sentence is front-loaded and free of padding, but this is under-specification rather than true conciseness; there is room for one clarifying clause at no cost to brevity.
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 is structurally simple (one required integer, no nested objects, no output schema), yet a mutation tool with a 0%-documented parameter and no return information leaves the agent without enough to call it confidently or predict its effect.
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 0% on the single required parameter alert_id, and the description supplies nothing about where the ID comes from, its format, or what happens if it refers to an already-paused or nonexistent alert. The description therefore does not compensate for the schema gap.
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?
"Pause an active alert." gives a verb and a resource, but it is nearly a restatement of the title "Pause Alert" and adds only the qualifier "active." It does not distinguish this reversible pause from the sibling delete_alert, which is the most consequential ambiguity for an agent choosing among alert 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?
No when-to-use guidance is given: nothing says to prefer this over delete_alert when an alert should be temporarily silenced versus permanently removed, and nothing states the prerequisite that the alert must currently be active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete an alert.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the irreversibility risk is largely covered. The description's addition of "Permanently" reinforces that but adds little else — nothing about errors when the alert_id does not exist, cascade effects on related entities, or confirmation requirements.
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?
A single front-loaded sentence with no filler. It is efficient and unambiguous as far as it goes, though its brevity stems partly from under-specification rather than discipline.
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 destructive tool whose annotations already flag destruction, this is close to minimally adequate. Missing are the lookup source for alert_id and post-delete behavior, which matter for a permanent operation.
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?
One required parameter with 0% schema description coverage, and the description says nothing about alert_id — no format, range, source, or how to obtain a valid value. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("delete an alert"), and the adverb "Permanently" implicitly distinguishes it from the sibling deactivate_alert. It does not explicitly name that sibling, so differentiation is inferential rather than stated.
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?
No explicit when-to-use or when-not-to-use guidance, and no named alternative. The agent must infer from the word "Permanently" that deactivate_alert is the reversible option; deleting is otherwise never framed against it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your alerts, including recent attempts and deliveries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that results bundle recent delivery attempts, which is genuine context beyond the annotations, but it doesn't say whether all alerts are returned, how they are ordered, or whether results are truncated.
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?
A single short sentence that front-loads the action and appends the one useful detail about return content. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool, the essentials are present, but with no output schema and no pagination or volume hints, an agent can't predict how large the response is or whether it covers all alerts. One clause on scope (e.g., "returns all alerts for your account") would close the gap.
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 takes zero parameters, so there is no parameter meaning for the description to supply; baseline 4 applies. The schema is empty and correctly so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List your alerts") and adds that results include "recent attempts and deliveries," which tells the agent what content comes back. It is clearly separable from the mutation siblings (create_alert, delete_alert, activate_alert, deactivate_alert) by name, though it doesn't explicitly contrast with listing siblings like list_changes or list_wire.
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?
There is no explicit when-to-use or when-not-to-use guidance and no named alternative. However, with zero parameters and an unambiguous name, the usage is strongly implied: this is the unfiltered read-only listing of alerts, as opposed to the create/delete/activate siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate score of company guidance versus reported actuals. One point per report period.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Listing symbol of the filer. | |
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| start_timestamp | No | System timestamp; Inclusive ISO 8601 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the behavior of 'one point per report period,' which is useful, but it does not disclose what happens when guidance data is missing, how the aggregate is computed across periods, or the exact output format. It does not contradict 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 two concise sentences, front-loaded with the core concept and free of fluff. It is appropriately sized for a simple read-only tool, though it could benefit from a bit more detail on the output without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should explain what the tool returns and how to interpret the score. It only says 'aggregate score' and 'one point per report period,' leaving ambiguity about the return type (e.g., number, object) and handling of edge cases like no data. This is insufficient for an agent to confidently use the 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?
The input schema provides descriptions for all three parameters, achieving 100% coverage, so the baseline is 3. The description does not add any additional meaning about how symbol, start_timestamp, or end_timestamp affect the aggregation. It relies entirely on the schema, which is adequate but not enhanced.
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 tool computes an aggregate score comparing company guidance to reported actuals, with one point per report period. This conveys a specific verb (aggregate) and resource (guidance vs actuals), and it conceptually distinguishes from sibling tools like list_guidance or list_guidance_outcomes, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as list_guidance or market_signal. The description implies it is for scoring, but it does not state conditions, exclusions, or scenarios where another tool would be more appropriate. Usage context is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify key stakeholders for a query, with optional context and instructions. Commonly ~2 minutes; call once. For Chat Agents: [If a user is waiting on this turn, tell them it takes ~2 minutes and get explicit approval before calling. If no one is waiting (one-shot / autonomous), call and wait.]
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| detail | No | essential:minimal; standard:scored+citable; full:all. | full |
| context | No | Additional context | |
| instructions | No | Additional guidance | |
| end_timestamp | No | As-of system timestamp; inclusive ISO 8601; null=realtime |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false. The description adds meaningful context beyond them: an expected ~2 minute latency and the recommendation to call only once, which helps an agent set expectations and avoid redundant calls. The chat-agent approval protocol is a useful behavioral disclosure for interactive contexts.
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?
Purpose is front-loaded in the first sentence, followed by the latency/call-frequency note and then the agent-specific protocol. The bracketed chat-agent block is somewhat verbose but each part carries actionable instruction, so little is wasted.
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 read-only, open-world research tool with no output schema, the description covers the essentials: what it does, how long it takes, call frequency, and how to handle a waiting user. Return-value detail is not needed since no output schema exists. Only the omission of when-to-use-vs-siblings keeps it from a 5.
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 80%, so the schema already documents query, detail, context, instructions, and end_timestamp. The description only echoes 'query, with optional context and instructions' without adding format or semantic detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Identify key stakeholders for a query') that is clearly distinct from siblings like retrieve_entity or search_events. It does not name or contrast against any sibling explicitly, but the purpose is unambiguous on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides operational guidance ('call once') and a conditional workflow for chat vs autonomous agents, which implies usage context. However, it never states when to choose this over alternatives such as retrieve_entity or retrieve_event_developments, leaving sibling selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Qualitative wording changes between consecutive earnings press releases: what the filer started saying, stopped saying, or now says differently.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | timestamp: newest first; materiality: highest materiality_score first. | timestamp |
| limit | No | ||
| detail | No | essential:finding; standard:citable; full:all. | full |
| impact | No | Match any. | |
| symbols | No | Match any. | |
| fiscal_year | No | ||
| change_kinds | No | Match any. | |
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| fiscal_quarter | No | ||
| start_timestamp | No | System timestamp; Inclusive ISO 8601 | |
| change_categories | No | Match any. | |
| min_materiality_score | No | 0-.2 reword; .2-.4 weak; .4-.6 mod; .6-.8 high; .8-1 must-read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive. The description adds useful behavioral context beyond that: it is a diff-style tool comparing consecutive releases and reporting started/stopped/differently wording. It does not cover pagination or result shape, but the annotations lower the burden for safety-related disclosure.
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?
A single, front-loaded sentence with no filler. It defines the resource, the comparison basis, and the output categories efficiently, earning its place fully.
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 12 filter parameters and no output schema, the description adequately explains the tool's subject and result types at a high level. It could add more detail about how consecutive releases are determined or what a result entry contains, but the schema covers the parameters and the description covers the domain.
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 75%, so the schema carries most parameter meaning. The description adds no parameter-specific detail, but it does establish the core concept (wording changes) that makes parameters like change_kinds and change_categories interpretable. This meets the baseline for high schema coverage.
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 resource (qualitative wording changes between consecutive earnings press releases) and spells out the three kinds of results (started saying, stopped saying, now says differently). This clearly distinguishes it from siblings like list_guidance or list_wire, which target different content.
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 implies when to use the tool: whenever an agent needs qualitative wording diffs across earnings releases. However, it names no alternatives and gives no explicit when-not-to-use guidance, so the usage context is clear but not contrasted with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forward-looking guidance issued by public companies, grouped into series with revision history.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | timestamp: recently updated; guided_period_end: period date; comparable: strongest like-for-like number in the match set; revision_delta: largest midpoint move. | timestamp |
| limit | No | ||
| detail | No | essential:quotes; standard:citable; full:all. | full |
| symbols | No | Match any. | |
| segments | No | Match any. 'null' is consolidated. | |
| metric_keys | No | Match any. | |
| values_mode | No | all: revision history, newest first; latest: newest observation only. | all |
| metric_basis | No | Match any. | |
| source_types | No | Match any. Document class the observation was read from. | |
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| start_timestamp | No | System timestamp; Inclusive ISO 8601 | |
| guided_fiscal_year | No | ||
| guided_period_type | No | Match any. | |
| revision_direction | No | Match any; latest observation only. | |
| guided_period_end_to | No | Inclusive guided period-end date. | |
| guided_fiscal_quarter | No | ||
| guided_period_end_from | No | Inclusive guided period-end date. | |
| metric_key_exact_match | No | true: exact metric_keys, case-insensitive; false: case-insensitive substring. Ignored without metric_keys. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false) already declare the read-only safety profile. The description adds one behavioral trait: output is 'grouped into series with revision history,' which is useful but limited. It does not mention sorting defaults, pagination, or how revision history is represented.
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?
A single, front-loaded sentence with no redundant words. It conveys the core purpose and the key behavioral nuance (grouping and revision history) efficiently.
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 18 parameters and no output schema, the description is too terse. It lacks an explanation of the returned structure, what 'series' means in practice, and how to interpret revision history. An agent would need to infer much from parameter names and examples.
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 83%, so the schema itself documents most parameters (e.g., sort meanings, detail levels, filters). The description adds no parameter-level context beyond what the schema provides, aligning with the baseline for high coverage.
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 identifies a specific verb ('list') and resource ('forward-looking guidance issued by public companies'), and adds distinguishing detail ('grouped into series with revision history'). It is clear but does not explicitly contrast with siblings like list_guidance_outcomes, so it doesn't fully differentiate within the tool family.
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?
There is no guidance on when to use this tool versus the alternatives (e.g., list_guidance_outcomes, search_developments, list_wire). The description only states what it does without any 'use this when...' context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Company guidance versus the reported actual.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | timestamp: newest actual first; outcome_abs: largest |score| first. | timestamp |
| limit | No | ||
| detail | No | essential:identity; standard:citable; full:all. | full |
| symbols | No | Match any. | |
| outcomes | No | Match any. Omit: resolved labels only. | |
| segments | No | Match any. 'null' is consolidated. | |
| metric_keys | No | Match any. | |
| metric_basis | No | Match any. | |
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| start_timestamp | No | System timestamp; Inclusive ISO 8601 | |
| guided_fiscal_year | No | ||
| guided_period_type | No | Match any. | |
| guided_period_end_to | No | Inclusive guided period-end date. | |
| guided_fiscal_quarter | No | ||
| guided_period_end_from | No | Inclusive guided period-end date. | |
| metric_key_exact_match | No | true: exact metric_keys, case-insensitive; false: case-insensitive substring. Ignored without metric_keys. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide readOnlyHint=true and destructiveHint=false, which are transparent, but the description adds no behavioral details beyond that. It does not mention that the tool returns a list, supports filtering, or has any default behavior. The vague 'versus' phrasing does not clarify the tool's side effects or data manipulation.
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 extremely concise (one short fragment), but it lacks a verb and a clear subject-predicate structure. It is not well-formed prose and does not communicate the tool's core action effectively. While brevity is positive, this is too terse to be useful.
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 has 16 parameters and a complex schema, the description provides essentially no context. It does not explain what a 'guidance outcome' is, how it relates to guidance versus actuals, or what the output represents. The description is entirely inadequate for the complexity of the 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?
The schema has high coverage (81%) with descriptions for most parameters, so baseline is 3. However, the tool description adds no additional semantics to the parameters; it relies entirely on the schema. For example, the description does not clarify how 'metric_key_exact_match' behaves or what 'segments' represents beyond the schema's own text.
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 'Company guidance versus the reported actual.' is a fragment, not a sentence with a verb. It does not state that the tool lists guidance outcomes, making its primary function unclear. The title 'List Guidance Outcomes' is more informative than the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides zero guidance on when to use this tool versus its siblings (e.g., list_guidance, list_wire). There is no mention of scenarios, filters, or how this tool differs from alternatives. A user would not know if this is the right tool for their query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the most recent wire items that match the given filters.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | essential:minimal; standard:citable; full:all. | full |
| novelty | No | Match any. | |
| recency | No | Match any. | |
| sectors | No | Match any. | |
| entities | No | Match any. | |
| countries | No | Match any; lowercase ISO 3166-1 alpha-2 | |
| publisher | No | Match any. | |
| categories | No | Match any. | |
| factuality | No | Match any. | |
| industries | No | Match any. | |
| max_records | No | ||
| content_type | No | Match any. | |
| asset_classes | No | Match any. | |
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| start_timestamp | No | System timestamp; Inclusive ISO 8601 | |
| entity_relevance | No | Match any. | |
| source_relationship | No | Match any. | |
| max_entity_sentiment | No | ||
| min_entity_sentiment | No | +-.2 neutral; +-.2-.6 mod; +-.6+ strong; both: >=min OR <=max | |
| min_importance_score | No | 0-.2 noise; .2-.4 low; .4-.6 mod; .6-.8 high; .8-1 critical | |
| min_trustworthiness_score | No | <.2 anon; .4-.6 mod; .6+ reputable; .8+ official |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint and destructiveHint annotations, stating a read-only 'Return' operation. It does not disclose additional behavioral details such as pagination, rate limits, or default ordering beyond 'most recent', but the annotations already cover the primary safety aspect, so the bar is lower.
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, concise sentence that front-loads the action and object. It is appropriately sized for a simple filtering operation, with no redundant or extraneous wording.
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?
Since there is no output schema, the description should give some indication of the return structure, but it only says 'wire items' without detailing fields or format. It also lacks any mention of result ordering, pagination, or limits beyond the implicit 'most recent'. This is adequate for a domain-savvy agent but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has high parameter description coverage (90%) with most parameters having at least 'Match any.' or examples. The tool description adds no extra meaning to the parameters; the baseline of 3 applies because the schema already provides adequate information.
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 verb 'Return' and the resource 'wire items', with a scope of 'most recent' and 'matching filters'. It distinguishes the tool from potentially similar ones like search_developments or search_events by its specific focus on wire items, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many siblings (e.g., search_developments, wire_storyline). It does not mention any conditions or scenarios that would make this tool preferable, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-bar wire attention (count) and net-sum entity sentiment (sum, std) for one sector, country, or asset class. Max 60d history.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | One sector, country (ISO 3166-1 alpha-2, lowercase), or asset class. | |
| novelty | No | Match any. | |
| resolution | No | Bucket length in UTC days; 1d-30d. | 1d |
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| start_timestamp | No | System timestamp; Inclusive ISO 8601; omitted=last 14 bars; max 60d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate read-only, and the description is consistent, adding context about the data shape (count, sum, std) and the 60-day limit. No side effects are implied.
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, well-structured sentence that front-loads the key output metrics and scope. It is concise without sacrificing necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain the output format beyond the mentioned metrics, nor does it provide context on how the data is organized (e.g., time series, bar buckets). It relies on parameter descriptions for 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?
The schema already covers all parameters with descriptions (100% coverage), so the tool description adds little extra. The baseline is 3, and no additional semantic information about parameters is provided.
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 specifies the tool's function: it returns per-bar wire attention (count) and net-sum entity sentiment (sum, std) for a single sector, country, or asset class, with a 60-day max. This distinguishes it from sibling tools like list_wire or search_events.
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?
No explicit guidance is provided on when to use this tool versus alternatives. The description does not mention typical use cases or conditions that favor this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific development by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | essential:minimal; standard:scored+citable; full:all. | full |
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| development_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond the read-only retrieval, such as mention of return format or potential side effects. It does not contradict annotations, but also does not enrich the behavioral understanding beyond what is already declared.
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, front-loaded sentence that directly states the core action. It is concise with no wasted words. However, it is so brief that it omits usage context, but that is a content issue rather than a structural one; the structure itself is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one required parameter and two optional ones, the description combined with the schema provides enough to call the tool correctly. However, it lacks guidance on when to use this tool vs siblings, and does not describe the response format (though no output schema exists). Given the low complexity, it is minimally complete but leaves key usage decisions to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (two of three parameters have descriptions). The tool description reinforces the development_id parameter by saying 'by its ID', but does not add new meaning to any parameters. The schema already explains the detail enum and end_timestamp semantics, so the description adds little 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 'Retrieve a specific development by its ID' clearly states the action (retrieve), the resource (development), and the key identifier (ID). It is specific and unambiguous, but it does not explicitly distinguish this from sibling tools like search_developments or retrieve_entity, so it misses the 'distinguishes from siblings' criterion for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_developments or retrieve_event_developments. It does not mention any exclusions, prerequisites, or conditions under which another tool would be more appropriate. This is a clear gap in usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Realtime context package for one entity.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | Entity name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and destructiveHint annotations already communicate that this is a read-only, non-destructive operation. The description adds no side effects, error behaviors, or special runtime behavior, so it is neutral but not contradictory.
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 very short and has no fluff, making it easy to scan. It loses a point because the wording is vague and 'realtime context package' is not a precise term, but it is concise.
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 no output schema, the description should at least explain what the context package contains, how current it is, or what happens for an unknown entity. None of that is present, so an agent cannot predict the tool's output or failure modes.
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 only parameter, entity, is fully described in the schema with examples and constraints. The description adds no additional meaning beyond the schema, so with 100% schema coverage the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Realtime context package for one entity' is a noun phrase and does not clearly state what the tool does or what it returns. It identifies the entity parameter but not the nature of the context package, and it does not distinguish this retrieval from sibling tools like retrieve_development or search_events.
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?
There is no guidance on when to use this tool versus the many related sibling tools. It does not mention that this is for a single entity by exact name, or when to choose search_developments, retrieve_development, or market_signal instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all developments associated with a known event_id. Filters for timestamp and occurrence are available. Track and understand the full event lifecycle through its developments.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | essential:minimal; standard:scored+citable; full:all. | full |
| event_id | Yes | ||
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| start_timestamp | No | System timestamp; Inclusive ISO 8601 | |
| include_future_developments | No | Include future occurrence times relative to end_timestamp or now. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the annotations (readOnlyHint=true) by using 'retrieve' and 'track' without mentioning side effects. It adds that filters are available, which gives a sense of the tool's behavior. However, it does not describe the response format or any edge cases (e.g., empty results), and relies on the annotations for safety transparency.
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, consisting of two clear sentences. It front-loads the primary action and immediately specifies the required context (known event_id). No redundant or vague wording dilutes the message.
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 absence of an output schema, the description provides enough context by stating that it returns all developments and helps track the full lifecycle. It does not enumerate response fields, but for a read-only retrieval tool this is acceptable. It could be slightly more complete by mentioning that the result is a list, but the plural 'developments' already implies that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for detail, start/end timestamps, and include_future_developments, but event_id and limit lack explicit descriptions. The tool description says 'filters for timestamp and occurrence' which partially covers the timestamp and future-occurrence parameters, but does not clarify event_id or limit semantics. Overall, parameter guidance is adequate but incomplete.
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 tool's purpose: to retrieve all developments for a known event_id. It uses a specific verb ('retrieve') and identifies the resource ('developments') and the key qualifier (associated with a known event_id), distinguishing it from sibling tools like retrieve_development (singular) and search_developments (search-based).
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 implies when to use the tool: when you have a known event_id and need its developments. It also mentions that filters for timestamp and occurrence are available, providing some usage context. However, it does not explicitly contrast with alternatives like search_developments or retrieve_development, leaving some ambiguity about when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the public companies most exposed to a theme, event or trend described in plain language.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| detail | No | essential:minimal; standard:scored+citable; full:all. | full |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. Beyond that the description adds nothing behavioral: no indication of how results are scored/ranked, latency, or result-count semantics tied to the limit parameter.
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?
A single front-loaded sentence with no waste. It is appropriately sized, though its brevity is also the source of the gaps elsewhere.
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 no output schema and thin parameter documentation, the description should carry more of the burden. It does not say what a result contains, how many companies are returned, or what the detail levels change, leaving an agent under-informed for a 3-parameter screening 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 description coverage is only 33% and the description supplies no parameter meaning at all. The limit range (1-40) and the detail enum's effect on output (essential/standard/full) are left entirely to the schema, and the description never explains how the plain-language query is interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Find') and resource ('public companies') with the scoping notion of thematic exposure. It is distinguishable from siblings like search_events or identify_stakeholders, though it does not explicitly contrast itself with any of them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'described in plain language' hints at the expected input style, but there is no guidance on when to use this versus the many alert/event/entity siblings, no prerequisites, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for developments semantically (or not). Various filters available: timestamp, development type, stakeholder impact, symbols, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| detail | No | essential:minimal; standard:scored+citable; full:all. | full |
| symbols | No | Match any. | |
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| start_timestamp | No | System timestamp; Inclusive ISO 8601 | |
| development_type | No | ||
| max_impact_score | No | ||
| min_impact_score | No | +-.5+ strong; 0..+-.5 weak; 0 neutral; both: >=min OR <=max | |
| min_surprise_score | No | 0-.2 known; .2-.4 expected; .4-.6 modest; .6-.8 notable; .8-1 shock | |
| min_confidence_score | No | <.2 unreliable; .4-.6 incomplete; .6+ strong; .8+ explicit | |
| min_importance_score | No | 0-.2 noise; .2-.4 minor; .4-.6 expected/mod; .6-.8 material; .8-1 critical | |
| end_occurrence_timestamp | No | Real-world occurrence timestamp; Inclusive ISO 8601 | |
| start_occurrence_timestamp | No | Real-world occurrence timestamp; Inclusive ISO 8601 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a small behavioral nuance with 'semantically (or not)', indicating the query can be semantic or keyword-based, but it does not disclose output shape, ordering, pagination, or how filters combine. This is acceptable but not rich.
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 efficient sentence that front-loads the core purpose and then lists filter categories. 'Various' and 'and more' are slightly vague but not wasteful. It earns a high score for compactness and readability.
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 14 optional parameters, no output schema, and no required fields, the description is too thin to fully contextualize the tool. It does not explain what a development is, how filters interact, what results look like, or how this differs from search_events. An agent would need to rely heavily on the schema and sibling tool names to use this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, and the schema itself documents most parameters well, including score thresholds and timestamp semantics. The description adds a high-level grouping of filters but does not clarify the remaining undocumented parameters (limit, query, development_type, max_impact_score). It does not meaningfully compensate for the small coverage gap.
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 action ('Search for developments') and notes the search can be semantic or not, which gives the agent a clear sense of the tool's core function. It also lists broad filter categories (timestamp, development type, stakeholder impact, symbols), helping distinguish it from tools like retrieve_development. However, it does not explicitly differentiate itself from sibling search_events or define what a 'development' is.
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 implies usage: use this when you need to search developments with optional filters. It does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as retrieve_development or search_events. The guidance is essentially inferred from the tool's name and filter list rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for events semantically (or not). Various filters available: timestamp, occurrence, event type, symbols, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| detail | No | essential:minimal; full:all. | full |
| symbols | No | Match any. | |
| event_type | No | ||
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| start_timestamp | No | System timestamp; Inclusive ISO 8601 | |
| developments_per_event | No | ||
| include_future_developments | No | Include future occurrence times relative to end_timestamp or now. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the 'semantically (or not)' behavior and a vague mention of filters, but does not disclose result format, pagination, or the meaning of 'occurrence'. It provides minimal extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and efficient, front-loading the core purpose and listing a few filters. It wastes no words, though it could be slightly more informative without losing conciseness.
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 9 parameters and no output schema, the description is far too brief. It omits critical details like what 'semantically (or not)' means, how filters combine, and what the response looks like. An agent would struggle to use this tool effectively without additional information.
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 56%, so the schema partially documents parameters. The description mentions some filters (timestamp, event type, symbols) but does not add meaning for undocumented ones like limit, query, or developments_per_event. It partially compensates but is not thorough.
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 tool searches for events and mentions key filters like timestamp, event type, and symbols. It distinguishes from search_developments by focusing on events, but does not explicitly name alternatives, so it's clear but not fully differentiated.
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?
There is no guidance on when to use this tool versus sibling tools like search_developments or retrieve_event_developments. The description does not specify conditions for choosing this tool or any exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the novelty storyline for a wire item: the linear prior_wire_id ancestor chain plus first-degree branches (items that point at any ancestor).
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | essential:minimal; standard:citable; full:all. | full |
| novelty | No | Match any. | |
| wire_id | Yes | ||
| max_children | No | Branched children cap | |
| end_timestamp | No | System timestamp; Inclusive ISO 8601; null=realtime | |
| start_timestamp | No | System timestamp; Inclusive ISO 8601 | |
| max_ancestor_depth | No | Ancestor cap, including seed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation by saying 'Retrieve' and does not contradict it. However, it does not add significant behavioral details beyond the annotation, such as side effects or permissions. The added details about the output structure are more about results than behavior.
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, front-loaded sentence that efficiently conveys the core functionality. There is no redundant information, and the structure (verb + object + detail of result) is clear and direct.
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 gives a concrete idea of the output (ancestor chain and branches), which is sufficient for a retrieval tool. It does not mention the novelty filter, but the schema covers that. It is not as complete as the high-scoring example because it lacks any contextual note about when this storyline is relevant, but it is adequate for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 86% of parameters with descriptions (e.g., end_timestamp, max_children). The tool description does not add any additional meaning to parameters like novelty or detail, leaving their cryptic descriptions ('Match any', 'essential:minimal') unclarified. Since schema coverage is high, the baseline of 3 is appropriate.
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 action ('Retrieve') and the resource ('wire item'), and specifies the exact structure of the result: the linear ancestor chain plus first-degree branches. This distinguishes it from sibling tools like list_wire or search_events, which serve different purposes.
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?
No explicit guidance is provided on when to use this tool versus alternatives. It does not mention conditions like 'use when you need the full storyline' or contrast with list_wire or search_developments. The description is self-explanatory but leaves usage inference to the agent.
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.
create_alert7 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / conditions / anyOfRemoved value: -[
- {
- "additionalProperties": false,
- "properties": {
- "asset_classes": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "equities",
- "fixed_income",
- "currencies",
- "commodities",
- "crypto",
- "real_estate"
- ],
- "type": "string"
- },
- "maxItems": 6,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Asset Classes"
- },
- "categories": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 20,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "examples": [
- [
- "earnings"
- ]
- ],
- "title": "Categories"
- },
- "content_type": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "news",
- "analysis",
- "opinion",
- "press_release",
- "data_release"
- ],
- "type": "string"
- },
- "maxItems": 5,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Content Type"
- },
- "countries": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 50,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any; lowercase ISO 3166-1 alpha-2",
- "title": "Countries"
- },
- "entities": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 50,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any; names or tickers.",
- "examples": [
- [
- "NVDA",
- "Apple Inc."
- ]
- ],
- "title": "Entities"
- },
- "entity_relevance": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "primary",
- "significant",
- "contextual",
- "incidental"
- ],
- "type": "string"
- },
- "maxItems": 4,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Entity Relevance"
- },
- "factuality": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "confirmed",
- "reported",
- "rumor",
- "speculation",
- "forecast"
- ],
- "type": "string"
- },
- "maxItems": 5,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Factuality"
- },
- "industries": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 20,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Industries"
- },
- "max_entity_sentiment": {
- "anyOf": [
- {
- "maximum": 1,
- "minimum": -1,
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "title": "Max Entity Sentiment"
- },
- "min_entity_sentiment": {
- "anyOf": [
- {
- "maximum": 1,
- "minimum": -1,
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "+-.2 neutral; +-.2-.6 mod; +-.6+ strong; both: >=min OR <=max",
- "title": "Min Entity Sentiment"
- },
- "min_importance_score": {
- "anyOf": [
- {
- "maximum": 1,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "0-.2 noise; .2-.4 low; .4-.6 mod; .6-.8 high; .8-1 critical",
- "title": "Min Importance Score"
- },
- "min_trustworthiness_score": {
- "anyOf": [
- {
- "maximum": 1,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "<.2 anon; .4-.6 mod; .6+ reputable; .8+ official",
- "title": "Min Trustworthiness Score"
- },
- "novelty": {
- "default": [
- "new",
- "update",
- "correction"
- ],
- "description": "Match any.",
- "items": {
- "enum": [
- "new",
- "update",
- "duplicate",
- "correction"
- ],
- "type": "string"
- },
- "maxItems": 4,
- "minItems": 1,
- "title": "Novelty",
- "type": "array"
- },
- "publisher": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 20,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Publisher"
- },
- "recency": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "realtime",
- "report_of_past",
- "report_of_future"
- ],
- "type": "string"
- },
- "maxItems": 3,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Recency"
- },
- "sectors": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "communication_services",
- "consumer_discretionary",
- "consumer_staples",
- "energy",
- "financials",
- "health_care",
- "industrials",
- "information_technology",
- "materials",
- "real_estate",
- "utilities"
- ],
- "type": "string"
- },
- "maxItems": 11,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Sectors"
- },
- "source": {
- "const": "wire",
- "title": "Source",
- "type": "string"
- },
- "source_relationship": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "first_party",
- "reporting",
- "second_hand"
- ],
- "type": "string"
- },
- "maxItems": 3,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Source Relationship"
- }
- },
- "required": [
- "source"
- ],
- "title": "WireAlertConditions",
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "development_types": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 10,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "examples": [
- [
- "corporate_action"
- ]
- ],
- "title": "Development Types"
- },
- "max_impact_score": {
- "anyOf": [
- {
- "maximum": 1,
- "minimum": -1,
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "title": "Max Impact Score"
- },
- "min_confidence_score": {
- "anyOf": [
- {
- "maximum": 1,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "<.2 unreliable; .4-.6 incomplete; .6+ strong; .8+ explicit",
- "title": "Min Confidence Score"
- },
- "min_impact_score": {
- "anyOf": [
- {
- "maximum": 1,
- "minimum": -1,
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "+-.5+ strong; 0..+-.5 weak; 0 neutral; both: >=min OR <=max",
- "title": "Min Impact Score"
- },
- "min_importance_score": {
- "anyOf": [
- {
- "maximum": 1,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "0-.2 noise; .2-.4 minor; .4-.6 expected/mod; .6-.8 material; .8-1 critical",
- "title": "Min Importance Score"
- },
- "min_surprise_score": {
- "anyOf": [
- {
- "maximum": 1,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "0-.2 known; .2-.4 expected; .4-.6 modest; .6-.8 notable; .8-1 shock",
- "title": "Min Surprise Score"
- },
- "source": {
- "const": "developments",
- "title": "Source",
- "type": "string"
- },
- "symbols": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 50,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any stakeholder ticker.",
- "examples": [
- [
- "NVDA",
- "AAPL"
- ]
- ],
- "title": "Symbols"
- }
- },
- "required": [
- "source"
- ],
- "title": "DevelopmentAlertConditions",
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "guided_period_type": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "quarter",
- "fiscal_year",
- "half",
- "multi_year",
- "other"
- ],
- "type": "string"
- },
- "maxItems": 5,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Guided Period Type"
- },
- "metric_basis": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "gaap",
- "non_gaap",
- "unspecified"
- ],
- "type": "string"
- },
- "maxItems": 3,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Metric Basis"
- },
- "metric_key_exact_match": {
- "default": false,
- "description": "true: exact metric_keys, case-insensitive; false: case-insensitive substring. Ignored without metric_keys.",
- "title": "Metric Key Exact Match",
- "type": "boolean"
- },
- "metric_keys": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 20,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "examples": [
- [
- "revenue"
- ]
- ],
- "title": "Metric Keys"
- },
- "revision_direction": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "new",
- "raised",
- "lowered",
- "maintained",
- "withdrawn"
- ],
- "type": "string"
- },
- "maxItems": 5,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any; the new observation.",
- "title": "Revision Direction"
- },
- "segments": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 8,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any. 'null' is consolidated.",
- "title": "Segments"
- },
- "source": {
- "const": "guidance",
- "title": "Source",
- "type": "string"
- },
- "source_types": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "earnings_release",
- "guidance_update",
- "interim_update",
- "earnings_call"
- ],
- "type": "string"
- },
- "maxItems": 4,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Source Types"
- },
- "symbols": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 50,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Symbols"
- }
- },
- "required": [
- "source"
- ],
- "title": "GuidanceAlertConditions",
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "guided_period_type": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "quarter",
- "fiscal_year",
- "half",
- "multi_year",
- "other"
- ],
- "type": "string"
- },
- "maxItems": 5,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Guided Period Type"
- },
- "metric_basis": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "gaap",
- "non_gaap",
- "unspecified"
- ],
- "type": "string"
- },
- "maxItems": 3,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Metric Basis"
- },
- "metric_key_exact_match": {
- "default": false,
- "description": "true: exact metric_keys, case-insensitive; false: case-insensitive substring. Ignored without metric_keys.",
- "title": "Metric Key Exact Match",
- "type": "boolean"
- },
- "metric_keys": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 20,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "examples": [
- [
- "revenue"
- ]
- ],
- "title": "Metric Keys"
- },
- "outcomes": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "significantly_exceeded",
- "exceeded",
- "in_line",
- "missed",
- "significantly_missed",
- "indeterminate"
- ],
- "type": "string"
- },
- "maxItems": 6,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Outcomes"
- },
- "segments": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 8,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any. 'null' is consolidated.",
- "title": "Segments"
- },
- "source": {
- "const": "guidance_outcomes",
- "title": "Source",
- "type": "string"
- },
- "symbols": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 50,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Symbols"
- }
- },
- "required": [
- "source"
- ],
- "title": "GuidanceOutcomeAlertConditions",
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "change_categories": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "metric_definition",
- "disclosed_metric",
- "accounting_policy",
- "reporting_structure",
- "guidance_basis",
- "results_attribution",
- "risk",
- "catalyst",
- "legal",
- "policy",
- "discrete_item",
- "capital_action",
- "strategy",
- "business_description",
- "product",
- "supply_chain",
- "property_and_equipment",
- "concentration",
- "governance",
- "compensation",
- "control_and_audit"
- ],
- "type": "string"
- },
- "maxItems": 21,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Change Categories"
- },
- "change_kinds": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "added",
- "removed",
- "modified"
- ],
- "type": "string"
- },
- "maxItems": 3,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Change Kinds"
- },
- "impact": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "positive",
- "negative",
- "neutral"
- ],
- "type": "string"
- },
- "maxItems": 3,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Impact"
- },
- "min_materiality_score": {
- "default": 0.4,
- "description": "0-.2 reword; .2-.4 weak; .4-.6 mod; .6-.8 high; .8-1 must-read",
- "maximum": 1,
- "minimum": 0,
- "title": "Min Materiality Score",
- "type": "number"
- },
- "source": {
- "const": "changes",
- "title": "Source",
- "type": "string"
- },
- "symbols": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "maxItems": 50,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Match any.",
- "title": "Symbols"
- }
- },
- "required": [
- "source"
- ],
- "title": "ChangeAlertConditions",
- "type": "object"
- }
-]Input schema / properties / conditions / oneOfAdded value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "asset_classes": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "equities",
+ "fixed_income",
+ "currencies",
+ "commodities",
+ "crypto",
+ "real_estate"
+ ],
+ "type": "string"
+ },
+ "maxItems": 6,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Asset Classes"
+ },
+ "categories": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "examples": [
+ [
+ "earnings"
+ ]
+ ],
+ "title": "Categories"
+ },
+ "content_type": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "news",
+ "analysis",
+ "opinion",
+ "press_release",
+ "data_release"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Content Type"
+ },
+ "countries": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any; lowercase ISO 3166-1 alpha-2",
+ "title": "Countries"
+ },
+ "entities": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any; names or tickers.",
+ "examples": [
+ [
+ "NVDA",
+ "Apple Inc."
+ ]
+ ],
+ "title": "Entities"
+ },
+ "entity_relevance": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "primary",
+ "significant",
+ "contextual",
+ "incidental"
+ ],
+ "type": "string"
+ },
+ "maxItems": 4,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Entity Relevance"
+ },
+ "factuality": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "confirmed",
+ "reported",
+ "rumor",
+ "speculation",
+ "forecast"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Factuality"
+ },
+ "industries": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Industries"
+ },
+ "max_entity_sentiment": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": -1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Entity Sentiment"
+ },
+ "min_entity_sentiment": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": -1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "+-.2 neutral; +-.2-.6 mod; +-.6+ strong; both: >=min OR <=max",
+ "title": "Min Entity Sentiment"
+ },
+ "min_importance_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "0-.2 noise; .2-.4 low; .4-.6 mod; .6-.8 high; .8-1 critical",
+ "title": "Min Importance Score"
+ },
+ "min_trustworthiness_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "<.2 anon; .4-.6 mod; .6+ reputable; .8+ official",
+ "title": "Min Trustworthiness Score"
+ },
+ "novelty": {
+ "default": [
+ "new",
+ "update",
+ "correction"
+ ],
+ "description": "Match any.",
+ "items": {
+ "enum": [
+ "new",
+ "update",
+ "duplicate",
+ "correction"
+ ],
+ "type": "string"
+ },
+ "maxItems": 4,
+ "minItems": 1,
+ "title": "Novelty",
+ "type": "array"
+ },
+ "publisher": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Publisher"
+ },
+ "recency": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "realtime",
+ "report_of_past",
+ "report_of_future"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Recency"
+ },
+ "sectors": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "communication_services",
+ "consumer_discretionary",
+ "consumer_staples",
+ "energy",
+ "financials",
+ "health_care",
+ "industrials",
+ "information_technology",
+ "materials",
+ "real_estate",
+ "utilities"
+ ],
+ "type": "string"
+ },
+ "maxItems": 11,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Sectors"
+ },
+ "source": {
+ "const": "wire",
+ "title": "Source",
+ "type": "string"
+ },
+ "source_relationship": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "first_party",
+ "reporting",
+ "second_hand"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Source Relationship"
+ }
+ },
+ "required": [
+ "source"
+ ],
+ "title": "WireAlertConditions",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "development_types": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 10,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "examples": [
+ [
+ "corporate_action"
+ ]
+ ],
+ "title": "Development Types"
+ },
+ "max_impact_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": -1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Impact Score"
+ },
+ "min_confidence_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "<.2 unreliable; .4-.6 incomplete; .6+ strong; .8+ explicit",
+ "title": "Min Confidence Score"
+ },
+ "min_impact_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": -1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "+-.5+ strong; 0..+-.5 weak; 0 neutral; both: >=min OR <=max",
+ "title": "Min Impact Score"
+ },
+ "min_importance_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "0-.2 noise; .2-.4 minor; .4-.6 expected/mod; .6-.8 material; .8-1 critical",
+ "title": "Min Importance Score"
+ },
+ "min_surprise_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "0-.2 known; .2-.4 expected; .4-.6 modest; .6-.8 notable; .8-1 shock",
+ "title": "Min Surprise Score"
+ },
+ "source": {
+ "const": "developments",
+ "title": "Source",
+ "type": "string"
+ },
+ "symbols": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any stakeholder ticker.",
+ "examples": [
+ [
+ "NVDA",
+ "AAPL"
+ ]
+ ],
+ "title": "Symbols"
+ }
+ },
+ "required": [
+ "source"
+ ],
+ "title": "DevelopmentAlertConditions",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "guided_period_type": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "quarter",
+ "fiscal_year",
+ "half",
+ "multi_year",
+ "other"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Guided Period Type"
+ },
+ "metric_basis": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "gaap",
+ "non_gaap",
+ "unspecified"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Metric Basis"
+ },
+ "metric_key_exact_match": {
+ "default": false,
+ "description": "true: exact metric_keys, case-insensitive; false: case-insensitive substring. Ignored without metric_keys.",
+ "title": "Metric Key Exact Match",
+ "type": "boolean"
+ },
+ "metric_keys": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "examples": [
+ [
+ "revenue"
+ ]
+ ],
+ "title": "Metric Keys"
+ },
+ "revision_direction": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "new",
+ "raised",
+ "lowered",
+ "maintained",
+ "withdrawn"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any; the new observation.",
+ "title": "Revision Direction"
+ },
+ "segments": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 8,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any. 'null' is consolidated.",
+ "title": "Segments"
+ },
+ "source": {
+ "const": "guidance",
+ "title": "Source",
+ "type": "string"
+ },
+ "source_types": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "earnings_release",
+ "guidance_update",
+ "interim_update",
+ "earnings_call"
+ ],
+ "type": "string"
+ },
+ "maxItems": 4,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Source Types"
+ },
+ "symbols": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Symbols"
+ }
+ },
+ "required": [
+ "source"
+ ],
+ "title": "GuidanceAlertConditions",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "guided_period_type": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "quarter",
+ "fiscal_year",
+ "half",
+ "multi_year",
+ "other"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Guided Period Type"
+ },
+ "metric_basis": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "gaap",
+ "non_gaap",
+ "unspecified"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Metric Basis"
+ },
+ "metric_key_exact_match": {
+ "default": false,
+ "description": "true: exact metric_keys, case-insensitive; false: case-insensitive substring. Ignored without metric_keys.",
+ "title": "Metric Key Exact Match",
+ "type": "boolean"
+ },
+ "metric_keys": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "examples": [
+ [
+ "revenue"
+ ]
+ ],
+ "title": "Metric Keys"
+ },
+ "outcomes": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "significantly_exceeded",
+ "exceeded",
+ "in_line",
+ "missed",
+ "significantly_missed",
+ "indeterminate"
+ ],
+ "type": "string"
+ },
+ "maxItems": 6,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Outcomes"
+ },
+ "segments": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 8,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any. 'null' is consolidated.",
+ "title": "Segments"
+ },
+ "source": {
+ "const": "guidance_outcomes",
+ "title": "Source",
+ "type": "string"
+ },
+ "symbols": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Symbols"
+ }
+ },
+ "required": [
+ "source"
+ ],
+ "title": "GuidanceOutcomeAlertConditions",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "change_categories": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "metric_definition",
+ "disclosed_metric",
+ "accounting_policy",
+ "reporting_structure",
+ "guidance_basis",
+ "results_attribution",
+ "risk",
+ "catalyst",
+ "legal",
+ "policy",
+ "discrete_item",
+ "capital_action",
+ "strategy",
+ "business_description",
+ "product",
+ "supply_chain",
+ "property_and_equipment",
+ "concentration",
+ "governance",
+ "compensation",
+ "control_and_audit"
+ ],
+ "type": "string"
+ },
+ "maxItems": 21,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Change Categories"
+ },
+ "change_kinds": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "added",
+ "removed",
+ "modified"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Change Kinds"
+ },
+ "impact": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "positive",
+ "negative",
+ "neutral"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Impact"
+ },
+ "min_materiality_score": {
+ "default": 0.4,
+ "description": "0-.2 reword; .2-.4 weak; .4-.6 mod; .6-.8 high; .8-1 must-read",
+ "maximum": 1,
+ "minimum": 0,
+ "title": "Min Materiality Score",
+ "type": "number"
+ },
+ "source": {
+ "const": "changes",
+ "title": "Source",
+ "type": "string"
+ },
+ "symbols": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Match any.",
+ "title": "Symbols"
+ }
+ },
+ "required": [
+ "source"
+ ],
+ "title": "ChangeAlertConditions",
+ "type": "object"
+ }
+]Input schema / properties / name / defaultAdded value: +nullInput schema / properties / receivers / items / anyOfRemoved value: -[
- {
- "additionalProperties": false,
- "properties": {
- "body_extra": {
- "anyOf": [
- {
- "additionalProperties": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "integer"
- },
- {
- "type": "number"
- },
- {
- "type": "boolean"
- },
- {
- "type": "null"
- }
- ]
- },
- "maxProperties": 10,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "Static keys merged into the top level of the body. String, number, boolean or null values only.",
- "title": "Body Extra"
- },
- "body_wrap_as_string": {
- "default": false,
- "description": "JSON-encode the envelope to a string before placing it under body_wrap_key. Requires body_wrap_key.",
- "title": "Body Wrap As String",
- "type": "boolean"
- },
- "body_wrap_key": {
- "anyOf": [
- {
- "maxLength": 64,
- "pattern": "^[A-Za-z0-9_-]+(\\.[A-Za-z0-9_-]+)?$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Place the alert envelope under this body key. Dot-separated for one level of nesting (e.g. variables.PAYLOAD).",
- "title": "Body Wrap Key"
- },
- "headers": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "maxProperties": 4,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "POST headers.",
- "title": "Headers"
- },
- "type": {
- "const": "webhook",
- "title": "Type",
- "type": "string"
- },
- "url": {
- "maxLength": 2048,
- "title": "Url",
- "type": "string"
- }
- },
- "required": [
- "type"
- ],
- "title": "WebhookReceiver",
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "type": {
- "const": "email",
- "title": "Type",
- "type": "string"
- }
- },
- "required": [
- "type"
- ],
- "title": "EmailReceiver",
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "chat_id": {
- "description": "Chat ID; start the alerts bot first.",
- "maxLength": 64,
- "title": "Chat Id",
- "type": "string"
- },
- "type": {
- "const": "telegram",
- "title": "Type",
- "type": "string"
- }
- },
- "required": [
- "type"
- ],
- "title": "TelegramReceiver",
- "type": "object"
- }
-]Input schema / properties / receivers / items / oneOfAdded value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "body_extra": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "maxProperties": 10,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Static keys merged into the top level of the body. String, number, boolean or null values only.",
+ "title": "Body Extra"
+ },
+ "body_wrap_as_string": {
+ "default": false,
+ "description": "JSON-encode the envelope to a string before placing it under body_wrap_key. Requires body_wrap_key.",
+ "title": "Body Wrap As String",
+ "type": "boolean"
+ },
+ "body_wrap_key": {
+ "anyOf": [
+ {
+ "maxLength": 64,
+ "pattern": "^[A-Za-z0-9_-]+(\\.[A-Za-z0-9_-]+)?$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Place the alert envelope under this body key. Dot-separated for one level of nesting (e.g. variables.PAYLOAD).",
+ "title": "Body Wrap Key"
+ },
+ "headers": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "maxProperties": 4,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "POST headers.",
+ "title": "Headers"
+ },
+ "type": {
+ "const": "webhook",
+ "title": "Type",
+ "type": "string"
+ },
+ "url": {
+ "maxLength": 2048,
+ "title": "Url",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "url"
+ ],
+ "title": "WebhookReceiver",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "const": "email",
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "title": "EmailReceiver",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "chat_id": {
+ "description": "Chat ID; start the alerts bot first.",
+ "maxLength": 64,
+ "title": "Chat Id",
+ "type": "string"
+ },
+ "type": {
+ "const": "telegram",
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "chat_id"
+ ],
+ "title": "TelegramReceiver",
+ "type": "object"
+ }
+]Input schema / titleAdded value: +"AlertInstructions"create_alert9 fields changedInput schema / properties / argumentsRemoved value: -{
- "additionalProperties": true,
- "description": "Endpoint arguments, dont provide system timestamps.",
- "examples": [
- {
- "entities": [
- "Apple Inc."
- ],
- "max_entity_sentiment": -0.3,
- "min_entity_sentiment": 0.3,
- "novelty": [
- "new",
- "update",
- "correction"
- ]
- }
- ],
- "title": "Arguments",
- "type": "object"
-}Input schema / properties / conditionsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "asset_classes": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "equities",
+ "fixed_income",
+ "currencies",
+ "commodities",
+ "crypto",
+ "real_estate"
+ ],
+ "type": "string"
+ },
+ "maxItems": 6,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Asset Classes"
+ },
+ "categories": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "examples": [
+ [
+ "earnings"
+ ]
+ ],
+ "title": "Categories"
+ },
+ "content_type": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "news",
+ "analysis",
+ "opinion",
+ "press_release",
+ "data_release"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Content Type"
+ },
+ "countries": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any; lowercase ISO 3166-1 alpha-2",
+ "title": "Countries"
+ },
+ "entities": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any; names or tickers.",
+ "examples": [
+ [
+ "NVDA",
+ "Apple Inc."
+ ]
+ ],
+ "title": "Entities"
+ },
+ "entity_relevance": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "primary",
+ "significant",
+ "contextual",
+ "incidental"
+ ],
+ "type": "string"
+ },
+ "maxItems": 4,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Entity Relevance"
+ },
+ "factuality": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "confirmed",
+ "reported",
+ "rumor",
+ "speculation",
+ "forecast"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Factuality"
+ },
+ "industries": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Industries"
+ },
+ "max_entity_sentiment": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": -1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Max Entity Sentiment"
+ },
+ "min_entity_sentiment": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": -1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "+-.2 neutral; +-.2-.6 mod; +-.6+ strong; both: >=min OR <=max",
+ "title": "Min Entity Sentiment"
+ },
+ "min_importance_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "0-.2 noise; .2-.4 low; .4-.6 mod; .6-.8 high; .8-1 critical",
+ "title": "Min Importance Score"
+ },
+ "min_trustworthiness_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "<.2 anon; .4-.6 mod; .6+ reputable; .8+ official",
+ "title": "Min Trustworthiness Score"
+ },
+ "novelty": {
+ "default": [
+ "new",
+ "update",
+ "correction"
+ ],
+ "description": "Match any.",
+ "items": {
+ "enum": [
+ "new",
+ "update",
+ "duplicate",
+ "correction"
+ ],
+ "type": "string"
+ },
+ "maxItems": 4,
+ "minItems": 1,
+ "title": "Novelty",
+ "type": "array"
+ },
+ "publisher": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Publisher"
+ },
+ "recency": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "realtime",
+ "report_of_past",
+ "report_of_future"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Recency"
+ },
+ "sectors": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "communication_services",
+ "consumer_discretionary",
+ "consumer_staples",
+ "energy",
+ "financials",
+ "health_care",
+ "industrials",
+ "information_technology",
+ "materials",
+ "real_estate",
+ "utilities"
+ ],
+ "type": "string"
+ },
+ "maxItems": 11,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Sectors"
+ },
+ "source": {
+ "const": "wire",
+ "title": "Source",
+ "type": "string"
+ },
+ "source_relationship": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "first_party",
+ "reporting",
+ "second_hand"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Source Relationship"
+ }
+ },
+ "required": [
+ "source"
+ ],
+ "title": "WireAlertConditions",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "development_types": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 10,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "examples": [
+ [
+ "corporate_action"
+ ]
+ ],
+ "title": "Development Types"
+ },
+ "max_impact_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": -1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Max Impact Score"
+ },
+ "min_confidence_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "<.2 unreliable; .4-.6 incomplete; .6+ strong; .8+ explicit",
+ "title": "Min Confidence Score"
+ },
+ "min_impact_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": -1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "+-.5+ strong; 0..+-.5 weak; 0 neutral; both: >=min OR <=max",
+ "title": "Min Impact Score"
+ },
+ "min_importance_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "0-.2 noise; .2-.4 minor; .4-.6 expected/mod; .6-.8 material; .8-1 critical",
+ "title": "Min Importance Score"
+ },
+ "min_surprise_score": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "0-.2 known; .2-.4 expected; .4-.6 modest; .6-.8 notable; .8-1 shock",
+ "title": "Min Surprise Score"
+ },
+ "source": {
+ "const": "developments",
+ "title": "Source",
+ "type": "string"
+ },
+ "symbols": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any stakeholder ticker.",
+ "examples": [
+ [
+ "NVDA",
+ "AAPL"
+ ]
+ ],
+ "title": "Symbols"
+ }
+ },
+ "required": [
+ "source"
+ ],
+ "title": "DevelopmentAlertConditions",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "guided_period_type": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "quarter",
+ "fiscal_year",
+ "half",
+ "multi_year",
+ "other"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Guided Period Type"
+ },
+ "metric_basis": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "gaap",
+ "non_gaap",
+ "unspecified"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Metric Basis"
+ },
+ "metric_key_exact_match": {
+ "default": false,
+ "description": "true: exact metric_keys, case-insensitive; false: case-insensitive substring. Ignored without metric_keys.",
+ "title": "Metric Key Exact Match",
+ "type": "boolean"
+ },
+ "metric_keys": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "examples": [
+ [
+ "revenue"
+ ]
+ ],
+ "title": "Metric Keys"
+ },
+ "revision_direction": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "new",
+ "raised",
+ "lowered",
+ "maintained",
+ "withdrawn"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any; the new observation.",
+ "title": "Revision Direction"
+ },
+ "segments": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 8,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any. 'null' is consolidated.",
+ "title": "Segments"
+ },
+ "source": {
+ "const": "guidance",
+ "title": "Source",
+ "type": "string"
+ },
+ "source_types": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "earnings_release",
+ "guidance_update",
+ "interim_update",
+ "earnings_call"
+ ],
+ "type": "string"
+ },
+ "maxItems": 4,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Source Types"
+ },
+ "symbols": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Symbols"
+ }
+ },
+ "required": [
+ "source"
+ ],
+ "title": "GuidanceAlertConditions",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "guided_period_type": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "quarter",
+ "fiscal_year",
+ "half",
+ "multi_year",
+ "other"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Guided Period Type"
+ },
+ "metric_basis": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "gaap",
+ "non_gaap",
+ "unspecified"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Metric Basis"
+ },
+ "metric_key_exact_match": {
+ "default": false,
+ "description": "true: exact metric_keys, case-insensitive; false: case-insensitive substring. Ignored without metric_keys.",
+ "title": "Metric Key Exact Match",
+ "type": "boolean"
+ },
+ "metric_keys": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "examples": [
+ [
+ "revenue"
+ ]
+ ],
+ "title": "Metric Keys"
+ },
+ "outcomes": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "significantly_exceeded",
+ "exceeded",
+ "in_line",
+ "missed",
+ "significantly_missed",
+ "indeterminate"
+ ],
+ "type": "string"
+ },
+ "maxItems": 6,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Outcomes"
+ },
+ "segments": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 8,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any. 'null' is consolidated.",
+ "title": "Segments"
+ },
+ "source": {
+ "const": "guidance_outcomes",
+ "title": "Source",
+ "type": "string"
+ },
+ "symbols": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Symbols"
+ }
+ },
+ "required": [
+ "source"
+ ],
+ "title": "GuidanceOutcomeAlertConditions",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "change_categories": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "metric_definition",
+ "disclosed_metric",
+ "accounting_policy",
+ "reporting_structure",
+ "guidance_basis",
+ "results_attribution",
+ "risk",
+ "catalyst",
+ "legal",
+ "policy",
+ "discrete_item",
+ "capital_action",
+ "strategy",
+ "business_description",
+ "product",
+ "supply_chain",
+ "property_and_equipment",
+ "concentration",
+ "governance",
+ "compensation",
+ "control_and_audit"
+ ],
+ "type": "string"
+ },
+ "maxItems": 21,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Change Categories"
+ },
+ "change_kinds": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "added",
+ "removed",
+ "modified"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Change Kinds"
+ },
+ "impact": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "positive",
+ "negative",
+ "neutral"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Impact"
+ },
+ "min_materiality_score": {
+ "default": 0.4,
+ "description": "0-.2 reword; .2-.4 weak; .4-.6 mod; .6-.8 high; .8-1 must-read",
+ "maximum": 1,
+ "minimum": 0,
+ "title": "Min Materiality Score",
+ "type": "number"
+ },
+ "source": {
+ "const": "changes",
+ "title": "Source",
+ "type": "string"
+ },
+ "symbols": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 50,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "title": "Symbols"
+ }
+ },
+ "required": [
+ "source"
+ ],
+ "title": "ChangeAlertConditions",
+ "type": "object"
+ }
+ ],
+ "examples": [
+ {
+ "entities": [
+ "NVDA",
+ "AAPL"
+ ],
+ "min_importance_score": 0.6,
+ "source": "wire"
+ }
+ ],
+ "title": "Conditions"
+}Input schema / properties / detailAdded value: +{
+ "default": "full",
+ "description": "essential:minimal; standard:citable; full:all.",
+ "enum": [
+ "full",
+ "standard",
+ "essential"
+ ],
+ "title": "Detail",
+ "type": "string"
+}Input schema / properties / interval_minutesRemoved value: -{
- "description": "Poll interval; multiple of 5.",
- "examples": [
- 15
- ],
- "maximum": 43200,
- "minimum": 5,
- "title": "Interval Minutes",
- "type": "integer"
-}Input schema / properties / lookback_minutesRemoved value: -{
- "anyOf": [
- {
- "maximum": 43200,
- "minimum": 5,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Defaults to interval_minutes",
- "title": "Lookback Minutes"
-}Input schema / properties / name / examplesPrevious value: -[
- "apple_wire_sentiment"
-]New value: +[
+ "nvda_aapl_headlines"
+]Input schema / properties / pathRemoved value: -{
- "description": "Endpoint the alert polls.",
- "enum": [
- "/v0/search/list_wire",
- "/v0/search/search_developments",
- "/v0/search/retrieve_event_developments",
- "/v0/search/search_events",
- "/v0/filings/list_guidance",
- "/v0/filings/list_changes",
- "/v0/filings/list_guidance_outcomes"
- ],
- "examples": [
- "/v0/search/list_wire"
- ],
- "title": "Path",
- "type": "string"
-}Input schema / properties / thresholdRemoved value: -{
- "default": 1,
- "description": "Items required to fire.",
- "minimum": 1,
- "title": "Threshold",
- "type": "integer"
-}Input schema / requiredPrevious value: -[
- "path",
- "arguments",
- "interval_minutes",
- "receivers"
-]New value: +[
+ "conditions",
+ "receivers"
+]execute_alertcreate_alert1 field changedInput schema / properties / path / enumPrevious value: -[
- "/v0/search/list_wire",
- "/v0/search/semantic_search",
- "/v0/search/search_developments",
- "/v0/search/retrieve_event_developments",
- "/v0/search/search_events",
- "/v0/filings/list_guidance",
- "/v0/filings/list_changes",
- "/v0/filings/list_guidance_outcomes"
-]New value: +[
+ "/v0/search/list_wire",
+ "/v0/search/search_developments",
+ "/v0/search/retrieve_event_developments",
+ "/v0/search/search_events",
+ "/v0/filings/list_guidance",
+ "/v0/filings/list_changes",
+ "/v0/filings/list_guidance_outcomes"
+]screen_stockssearch_developments1 field changedInput schema / properties / stakeholder_symbolRemoved value: -{
- "anyOf": [
- {
- "maxLength": 20,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "examples": [
- "NVDA"
- ],
- "title": "Stakeholder Symbol"
-}list_guidance1 field changedInput schema / properties / source_types / anyOfPrevious value: -[
- {
- "items": {
- "enum": [
- "earnings_release",
- "guidance_update",
- "earnings_call"
- ],
- "type": "string"
- },
- "maxItems": 3,
- "minItems": 1,
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "enum": [
+ "earnings_release",
+ "guidance_update",
+ "interim_update",
+ "earnings_call"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]create_alert1 field changedInput schema / properties / receivers / items / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "body_extra": {
- "anyOf": [
- {
- "additionalProperties": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "integer"
- },
- {
- "type": "number"
- },
- {
- "type": "boolean"
- },
- {
- "type": "null"
- }
- ]
- },
- "maxProperties": 10,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "Static keys merged into the top level of the body. String, number, boolean or null values only.",
- "title": "Body Extra"
- },
- "body_wrap_as_string": {
- "default": false,
- "description": "JSON-encode the envelope to a string before placing it under body_wrap_key. Requires body_wrap_key.",
- "title": "Body Wrap As String",
- "type": "boolean"
- },
- "body_wrap_key": {
- "anyOf": [
- {
- "maxLength": 64,
- "pattern": "^[A-Za-z0-9_-]+(\\.[A-Za-z0-9_-]+)?$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Place the alert envelope under this body key. Dot-separated for one level of nesting (e.g. variables.PAYLOAD).",
- "title": "Body Wrap Key"
- },
- "headers": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "maxProperties": 4,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "POST headers.",
- "title": "Headers"
- },
- "type": {
- "const": "webhook",
- "title": "Type",
- "type": "string"
- },
- "url": {
- "maxLength": 2048,
- "title": "Url",
- "type": "string"
- }
- },
- "required": [
- "type",
- "url"
- ],
- "title": "WebhookReceiver",
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "type": {
- "const": "email",
- "title": "Type",
- "type": "string"
- }
- },
- "required": [
- "type"
- ],
- "title": "EmailReceiver",
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "chat_id": {
- "description": "Chat ID; start the alerts bot first.",
- "maxLength": 64,
- "title": "Chat Id",
- "type": "string"
- },
- "type": {
- "const": "telegram",
- "title": "Type",
- "type": "string"
- }
- },
- "required": [
- "type",
- "chat_id"
- ],
- "title": "TelegramReceiver",
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "body_extra": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "maxProperties": 10,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Static keys merged into the top level of the body. String, number, boolean or null values only.",
+ "title": "Body Extra"
+ },
+ "body_wrap_as_string": {
+ "default": false,
+ "description": "JSON-encode the envelope to a string before placing it under body_wrap_key. Requires body_wrap_key.",
+ "title": "Body Wrap As String",
+ "type": "boolean"
+ },
+ "body_wrap_key": {
+ "anyOf": [
+ {
+ "maxLength": 64,
+ "pattern": "^[A-Za-z0-9_-]+(\\.[A-Za-z0-9_-]+)?$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Place the alert envelope under this body key. Dot-separated for one level of nesting (e.g. variables.PAYLOAD).",
+ "title": "Body Wrap Key"
+ },
+ "headers": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "maxProperties": 4,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "POST headers.",
+ "title": "Headers"
+ },
+ "type": {
+ "const": "webhook",
+ "title": "Type",
+ "type": "string"
+ },
+ "url": {
+ "maxLength": 2048,
+ "title": "Url",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "title": "WebhookReceiver",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "const": "email",
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "title": "EmailReceiver",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "chat_id": {
+ "description": "Chat ID; start the alerts bot first.",
+ "maxLength": 64,
+ "title": "Chat Id",
+ "type": "string"
+ },
+ "type": {
+ "const": "telegram",
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "title": "TelegramReceiver",
+ "type": "object"
+ }
+]create_alert3 fields changedInput schema / properties / interval_minutes / maximumAdded value: +43200Input schema / properties / lookback_minutes / anyOfPrevious value: -[
- {
- "minimum": 5,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 43200,
+ "minimum": 5,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / receivers / items / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "body_extra": {
- "anyOf": [
- {
- "additionalProperties": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "integer"
- },
- {
- "type": "number"
- },
- {
- "type": "boolean"
- },
- {
- "type": "null"
- }
- ]
- },
- "maxProperties": 10,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "Static keys merged into the top level of the body. String, number, boolean or null values only.",
- "title": "Body Extra"
- },
- "body_wrap_as_string": {
- "default": false,
- "description": "JSON-encode the envelope to a string before placing it under body_wrap_key. Requires body_wrap_key.",
- "title": "Body Wrap As String",
- "type": "boolean"
- },
- "body_wrap_key": {
- "anyOf": [
- {
- "maxLength": 64,
- "pattern": "^[A-Za-z0-9_-]+(\\.[A-Za-z0-9_-]+)?$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Place the alert envelope under this body key. Dot-separated for one level of nesting (e.g. variables.PAYLOAD).",
- "title": "Body Wrap Key"
- },
- "headers": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "maxProperties": 4,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "POST headers.",
- "title": "Headers"
- },
- "type": {
- "const": "webhook",
- "title": "Type",
- "type": "string"
- },
- "url": {
- "maxLength": 2048,
- "title": "Url",
- "type": "string"
- }
- },
- "required": [
- "type",
- "url"
- ],
- "title": "WebhookReceiver",
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "type": {
- "const": "email",
- "title": "Type",
- "type": "string"
- }
- },
- "required": [
- "type"
- ],
- "title": "EmailReceiver",
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "chat_id": {
- "description": "Chat ID; start the alerts bot first.",
- "title": "Chat Id",
- "type": "string"
- },
- "type": {
- "const": "telegram",
- "title": "Type",
- "type": "string"
- }
- },
- "required": [
- "type",
- "chat_id"
- ],
- "title": "TelegramReceiver",
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "body_extra": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "maxProperties": 10,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Static keys merged into the top level of the body. String, number, boolean or null values only.",
+ "title": "Body Extra"
+ },
+ "body_wrap_as_string": {
+ "default": false,
+ "description": "JSON-encode the envelope to a string before placing it under body_wrap_key. Requires body_wrap_key.",
+ "title": "Body Wrap As String",
+ "type": "boolean"
+ },
+ "body_wrap_key": {
+ "anyOf": [
+ {
+ "maxLength": 64,
+ "pattern": "^[A-Za-z0-9_-]+(\\.[A-Za-z0-9_-]+)?$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Place the alert envelope under this body key. Dot-separated for one level of nesting (e.g. variables.PAYLOAD).",
+ "title": "Body Wrap Key"
+ },
+ "headers": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "maxProperties": 4,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "POST headers.",
+ "title": "Headers"
+ },
+ "type": {
+ "const": "webhook",
+ "title": "Type",
+ "type": "string"
+ },
+ "url": {
+ "maxLength": 2048,
+ "title": "Url",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "url"
+ ],
+ "title": "WebhookReceiver",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "const": "email",
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "title": "EmailReceiver",
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "chat_id": {
+ "description": "Chat ID; start the alerts bot first.",
+ "maxLength": 64,
+ "title": "Chat Id",
+ "type": "string"
+ },
+ "type": {
+ "const": "telegram",
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "chat_id"
+ ],
+ "title": "TelegramReceiver",
+ "type": "object"
+ }
+]search_developments1 field changedInput schema / properties / symbolsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 8,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "examples": [
+ [
+ "NVDA",
+ "AAPL"
+ ]
+ ],
+ "title": "Symbols"
+}search_events1 field changedInput schema / properties / symbolsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 8,
+ "minItems": 1,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Match any.",
+ "examples": [
+ [
+ "NVDA",
+ "AAPL"
+ ]
+ ],
+ "title": "Symbols"
+}activate_alertcreate_alertdeactivate_alertdelete_alertexecute_alertget_alertsguidance_biasidentify_stakeholderslist_changeslist_guidancelist_guidance_outcomeslist_wiremarket_signalretrieve_developmentretrieve_entityretrieve_event_developmentssearch_developmentssearch_eventswire_storylineLicensed, cited financial data for AI agents: news, filings, transcripts, research and tearsheets.
Evidence-backed capital-change intelligence and sourced financial data for AI agents
Financial intelligence for AI agents: market events, sentiment, technicals, news feed.
Private company data, entity-resolved news, targeted lists, and alternative signals for AI agents.
Add one secure layer between your agents and this server.
