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
Most tools are clearly scoped by action (create_alert, deactivate_alert, delete_alert, execute_alert) and resource (guidance_bias, list_guidance, list_wire). However, retrieve_development and retrieve_event_developments could be confused, and guidance_bias vs list_guidance_outcomes both relate to guidance outcomes versus actuals.
Naming mixes verb_noun (create_alert, delete_alert, list_guidance, retrieve_entity) with noun-based tools (guidance_bias, market_signal, identify_stakeholders). The retrieve_* and list_* prefixes are mostly consistent, but the noun-only tools break the pattern.
15 tools is within the reasonable range for a server covering alerts, earnings data, and market signals. The surface is substantial but not bloated, with several read-only information tools balanced by a full alert lifecycle.
The alert lifecycle is complete (create, activate, deactivate, delete, execute, list). The data exploration tools cover guidance, outcomes, wire, changes, and entities. Minor gaps exist—e.g., no update_alert for modifying existing alerts, and retrieve_entity is vague about what 'realtime context' includes, but core workflows are covered.
Activate an alert by setting its status to 'active'.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the direct effect (status becomes 'active') but does not mention any side effects, such as triggering notifications or other workflows. The annotations indicate it is not read-only and not destructive, but the description lacks detail on broader behavioral implications.
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, clear sentence with no redundancy. It is appropriately concise and well-structured.
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 simplicity of the operation, the description is largely sufficient. However, it could benefit from a brief note on typical use cases or relationship to other alert-management tools, but this is not critical for a basic activation action.
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 one required parameter, alert_id, which is not described in the tool description. While the name is self-explanatory, the description does not elaborate on its meaning or any constraints, and schema coverage is 0%.
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 'Activate', the resource 'alert', and the specific action of setting its status to 'active'. It is distinct from sibling tools like deactivate_alert, delete_alert, and execute_alert, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus the alternatives (e.g., deactivate_alert). There is no guidance on preconditions or typical scenarios, leaving some 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.
Create an alert that periodically polls an endpoint and delivers new results to your configured receivers (webhook, email, and/or telegram).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Unique label; auto-generated if omitted | |
| path | Yes | Endpoint the alert polls. | |
| arguments | Yes | Endpoint arguments, dont provide system timestamps. | |
| receivers | Yes | 1-2 unique targets. | |
| threshold | No | Items required to fire. | |
| interval_minutes | Yes | Poll interval; multiple of 5. | |
| lookback_minutes | No | Defaults to interval_minutes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=false and destructiveHint=false, so the description need not restate those. It does add useful context that the created alert will 'periodically poll an endpoint and deliver new results to receivers,' but it does not disclose side effects of the creation call itself—such as whether the alert starts active or requires activation, what response is returned, or any authorization or rate-limit requirements. These gaps are notable but not contradictory to 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 a single, focused sentence with no filler or redundant phrasing. It front-loads the verb and resource, and then adds the key behavioral detail about polling and delivery. It is concise and clear, though a slightly longer description could have provided extra lifecycle details without hurting structure.
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?
This is a 7-parameter tool with nested receiver objects and no output schema, so the description must carry a significant explanatory burden. It does not mention what the create call returns, whether the alert is immediately active or must be activated via activate_alert, or what failure modes exist during creation. The presence of activate_alert/deactivate_alert siblings makes the activation-status gap especially relevant, and the missing return-value information is a further completeness 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?
Schema description coverage is 100%, so the baseline is 3. The description only refers generically to 'an endpoint' and 'configured receivers,' which are already defined in the schema with detailed properties such as enum for path, receiver types, and interval constraints. It adds no extra meaning beyond what the schema provides, so it remains at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the imperative 'Create an alert' and immediately explains what the alert does: 'periodically polls an endpoint and delivers new results to your configured receivers.' This clearly states a specific verb and resource, and the polling behavior distinguishes it from alert management siblings like delete_alert, activate_alert, and get_alerts.
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 'periodically polls' implies this is for recurring scheduled monitoring, which is usable guidance. However, there is no explicit contrast with closely related siblings such as execute_alert (which likely triggers a one-time poll) or activate_alert (which may be needed to enable a newly created alert). No exclusions or 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deactivate an alert by setting its status to 'paused'.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnly=false and destructive=false, which the description aligns with by stating a non-destructive state change. The description adds specific context that the status becomes 'paused', but does not mention any permissions, reversibility, or side effects.
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 one sentence, highly concise, with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a single parameter and no output schema, the description provides the core action and effect. However, it does not explain any consequences of pausing (e.g., whether alerts remain active in some other state), which could be considered a minor 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?
Only one integer parameter alert_id is present. The schema does not include a description for alert_id, and the tool description does not elaborate on its meaning or format, beyond implying it identifies the alert.
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?
Clearly states the action (deactivate) and the resource (alert), and specifies the status change to 'paused'. This distinguishes it from sibling tools like activate_alert and delete_alert.
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 the tool is for pausing alerts, but does not explicitly contrast it with alternatives like activate_alert or delete_alert. It provides no explicit guidance on when to use this tool over others, relying on the user's understanding of the sibling names.
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 from the database.
| 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, so the description adds the nuance of 'permanently,' which is a useful behavioral detail beyond the annotation. However, it doesn't disclose any side effects, permissions, or what happens if the alert doesn't exist. The added context is minimal but non-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 a single, focused sentence with no filler. It is concise and front-loaded with the key action, making it easy to parse quickly.
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 delete operation with one parameter and no output schema, the description covers the core action. However, it omits potential caveats like irreversibility (beyond 'permanently'), cascading effects, or error behavior. Given the tool's simplicity, it is mostly complete but lacks a few details an agent might need.
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 no description for alert_id, and the tool description doesn't explain its purpose or how to obtain it. While the name 'alert_id' is self-explanatory, the description fails to add any meaning beyond the schema. With 0% schema coverage, the description should compensate but does not.
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 uses the specific verb 'delete' with the resource 'alert' and adds 'permanently' and 'from the database,' clearly distinguishing it from sibling tools like deactivate_alert (state change) and create_alert (creation). The intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like deactivate_alert. It doesn't state that deactivation is preferred for temporary disablement or that this is the only way to remove an alert permanently. The agent must infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an alert immediately to test it. Runs the exact same path as scheduled execution, including history and dedup.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond the annotations: it runs the exact same path as scheduled execution and includes history and dedup. This helps the agent understand side effects such as dedup counting and history recording, though it does not fully enumerate all possible downstream effects (e.g., notifications).
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—two sentences—and front-loads the core purpose. Every sentence adds useful information: immediate execution, same path as scheduled, and history/dedup behavior. No fluff or redundant 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?
The description gives enough context to understand the tool's input and behavior. It does not describe the return value or error cases, but given the simple alert_id input and the absence of an output schema, the missing output details are not a significant 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 only parameter, alert_id, is self-descriptive with its name and title, even though the schema does not provide a detailed description. The tool description does not elaborate on where to find the alert_id, but the parameter is straightforward enough given the sibling get_alerts tool.
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 'Execute' and the object 'alert', with the specific purpose of immediate testing. It further clarifies that it runs the exact same path as scheduled execution, which distinguishes it from simple activation and makes its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Execute an alert immediately to test it.' It does not explicitly name sibling tools as alternatives (e.g., activate_alert), but the mention of 'scheduled execution' and 'test it' strongly implies when this tool should be used versus merely enabling the alert.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all alerts for the authenticated user, including recent attempt and delivery history.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint true and destructiveHint false, and the description aligns with that by saying 'retrieve'. It adds the expectation of including delivery history, which gives useful behavioral context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, then adds relevant detail. There is no redundant or unnecessary language.
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 enough context for a simple no-parameter read-only listing tool, including the mention of recent attempt and delivery history. It does not describe response structure or pagination, but those are not critical for basic usage given the tool's simplicity.
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?
There are zero parameters and the schema already reflects that, so there is nothing meaningful to describe. The baseline for no parameters is appropriate, and the description does not mislead about inputs.
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), the resource (all alerts), and the scope (for the authenticated user), and it adds useful context about including recent attempt and delivery history. It is distinct from sibling tools like create_alert and execute_alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the read-only nature apparent but does not explicitly state when to prefer this tool over siblings or mention any limitations such as lack of filtering or pagination. Some guidance is implied by the verb 'retrieve' but not directly provided.
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=true and destructiveHint=false, so the description correctly doesn't repeat that. It adds valuable behavioral context by disclosing the ~2 minute duration and the 'call once' directive, plus the approval requirement for interactive scenarios. These traits are not captured in the annotations, making the description informative without redundancy.
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, with only two sentences that both earn their place. The main purpose is front-loaded in the first sentence, and the second sentence provides essential usage guidance. The bold formatting for the chat-agent instruction is clear and aids readability without adding bulk.
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?
While the tool has no output schema, the description does not hint at the return format or structure of stakeholders, which could be important for an agent. It also doesn't elaborate on when to use optional parameters like context or end_timestamp beyond the schema's basic descriptions. The core call guidance is present, but the description leaves gaps about expected output and parameter usage contexts.
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%, meaning most parameters are already described in the schema. The description mentions 'optional context and instructions', which mirrors the schema but adds no new meaning. It does not clarify the 'detail' enum values or when to use 'end_timestamp', relying on the schema's own descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Identify' and the resource 'key stakeholders for a query', making the tool's purpose specific and unambiguous. It stands apart from sibling tools (alerts, guidance, wire, search) by focusing on stakeholder identification, which is a unique function among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states that the tool is commonly ~2 minutes, should be called once, and gives specific instructions for chat agents on obtaining approval when a user is waiting. While it doesn't explicitly mention alternatives or when not to use it, the context is clear and sufficient for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
search_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_storylineEvidence-backed capital-change intelligence and sourced financial data for AI agents
Private company data, entity-resolved news, targeted lists, and alternative signals for AI agents.
Primary-source SEC filing intelligence and financial/disclosure reconciliation for AI agents.
Real-time financial news for AI agents: search by ticker and source, with sentiment and entities.
Add one secure layer between your agents and this server.
