AlphaAI

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

Annotations already indicate readOnly, openWorld, and idempotent behavior. The description supplements this with additional behavioral details: the strict gate only allowing high-actionability items, that medium items are excluded, the expected empty list outside market hours, and that results are ordered novelty-first with syndicated reprints collapsed by default. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is comprehensive and well-structured, with each sentence serving a distinct purpose (purpose, filter explanation, comparison to siblings, empty list handling, ordering/dedup). It is slightly verbose but justified given the tool's complexity. Could be slightly more concise without losing essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters (none required), output schema exists, and annotations are present, the description fully covers all aspects an AI agent needs: what the tool does, when to use it, how parameters affect results, expected edge cases (empty list), ordering, and deduplication. No gaps are evident.

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 covers all 5 parameters with good descriptions (100% coverage). The tool description adds context beyond the schema by explaining the interplay of parameters (e.g., min_novelty as a secondary threshold that drops post-event recaps, min_actionability floor differentiating between 'high' and 'medium'). However, some parameter information is redundant with schema descriptions, so not fully additional.

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 explicitly states the tool returns 'breaking, decision-grade news from the last few hours' and explains the primary filter (actionability score). It distinguishes itself from sibling tools like alphai_trending and alphai_ticker_news by clarifying what types of news are included (high actionability only) and by providing alternative tool suggestions for broader tape coverage.

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 clear guidance on when to use this tool vs alternatives: it mentions that medium-actionability stories never appear at default floor and advises using alphai_trending or alphai_ticker_news for broader tape. It also explains expected behavior outside US market hours (empty list expected) and suggests widening hours or min_actionability before concluding nothing happened.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description's mention of including filters adds some value but does not disclose further behavioral traits like rate limits or authentication needs. The description does not contradict 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, efficient sentence that front-loads the core action and key details. Every word is meaningful, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, an output schema (not shown but present), and rich annotations, the description is complete. It covers the essential information an agent needs to understand what the tool does and what it returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and schema description coverage at 100%, the description cannot add parameter-level meaning. However, it does explain what the output contains (filters), which indirectly adds value. Baseline 4 for no parameters 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 'List the caller's active ticker news-alert subscriptions' with a specific verb and resource. It also details what is included (filters). This distinguishes it from sibling tools like alphai_alerts_subscribe and alphai_alerts_unsubscribe which perform different actions.

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?

While not explicitly stating when to use or avoid this tool, the description clearly indicates its purpose for listing subscriptions. The context of sibling tools (subscribe, unsubscribe) implies it is for viewing, not modifying. However, no explicit alternatives or exclusions are given.

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

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

The description adds behavioral context beyond annotations: it clarifies partial update semantics (preserving omitted fields for existing subscriptions, defaulting min_relevance_score to 6 for new ones) and lists possible errors (tier_not_paid, unknown_ticker, limit_reached). Annotations already indicate idempotency, so the description adds value.

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: three sentences that front-load the main action and then add important details. No extraneous text.

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 presence of an output schema, the description does not need to explain return values. It covers key behaviors (partial update, defaults, errors) adequately for a subscription tool. Room for additional context about unsubscription but not required.

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?

While the input schema covers all parameters with descriptions, the tool description explains the behavioral meaning of omitting parameters (partial update) and the default for new subscriptions. This adds semantic clarity 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 clearly states the tool subscribes the caller to ticker news alerts, with specific verb and resource. It distinguishes from sibling tools like alphai_alerts_list and alphai_alerts_unsubscribe by focusing on subscription creation/modification.

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 the action and partial update behavior but does not explicitly indicate when to use this tool versus alternatives (e.g., when to use list or unsubscribe). No direct comparison to siblings is provided.

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

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

Annotations provide readOnlyHint=false, destructiveHint=true, idempotentHint=true. The description adds valuable context: idempotency details, specific return value for inactive alerts, and error handling. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences packed with essential information: purpose, idempotency, return values, and error case. No wasted words. Front-loaded with the main action.

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 one required parameter, output schema, and thorough annotations, the description covers all necessary behavioral nuances (idempotency, inactive case, error). No gaps detected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with one parameter 'ticker' described. The description adds no additional meaning beyond the schema, so baseline score 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 tool's purpose: soft-disable the caller's news-alert subscription for a given ticker. It uses a specific verb (unsubscribe) and resource (ticker alerts), and is easily distinguishable from siblings like alphai_alerts_subscribe and alphai_alerts_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (to unsubscribe) and details edge cases: idempotent behavior with {removed: false} for already inactive alerts, and raises unknown_ticker for invalid symbols. While it doesn't explicitly contrast with alternatives, the context is clear given sibling tools.

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

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

Annotations already provide readOnly, openWorld, and idempotent hints. Description adds critical behavioral details: enrichment content, copyright restriction on full body, and error behavior for unknown uid. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that efficiently convey purpose, enrichment, limitations, and error behavior. No redundant information, front-loads key action.

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 single-parameter tool with output schema, the description covers purpose, output content, important limitation (no full body), and error condition. Complete given the context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and parameter description in schema is adequate. Description reinforces the parameter but does not add new constraints or format details beyond what schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it fetches a single article by uid with full enrichment, distinguishing it from sibling tools that list or search articles. It also specifies what it does not serve (full body).

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?

Explicitly states it is the canonical single-article lookup and not a fuller view, implying appropriate use cases. Also mentions not_found error for unknown uid. Could be more direct about alternatives, but context is clear.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint. Description adds cursor-pagination details and unknown_ticker behavior, providing useful 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?

Concise, front-loaded with key purpose, efficient multi-sentence structure without repetition.

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 output schema present and rich annotations, description covers purpose, filtering, pagination, and shape equivalence to sibling tool. No 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?

Schema coverage is 100%, baseline 3. Description adds value by summarizing filter options and mentioning unknown_ticker behavior, slightly exceeding schema-only info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly identifies the tool as ownership-change news specifically SEC Form 4 and 13F filings. It distinguishes from sibling alphai_news_search by noting it's equivalent to searching with category='insider'.

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?

States when to use: for insider trades and institutional ownership moves. Mentions optional filters. Implies alternative of alphai_news_search but does not explicitly state when not to use.

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

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

Annotations already indicate read-only, open-world, idempotent behavior. The description adds details on pagination (opaque cursor), AND-matching for queries, and collapse_stories deduplication with sources_count. It does not specify default ordering or rate limits, but these are minor gaps.

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 sentences, front-loaded with purpose and filters, then pagination and special feature. No wasted words; every sentence serves a clear function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 params, pagination, collapse), the description covers key behaviors. Missing default ordering (likely by date) but pagination and collapse are well explained. Output schema exists, mitigating need to detail return fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value by explaining AND-matching for the 'q' parameter, opaque cursor for 'cursor', and collapse_stories effect in natural language, reinforcing schema definitions without redundant repetition.

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 an enriched financial news feed with specific filters (free-text, tickers, category, date range, min relevance). It distinguishes from siblings like alphai_ticker_news (single ticker) and alphai_insider_news by emphasizing broad search and collapse_stories deduplication.

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 for comprehensive filtered search but does not explicitly contrast with siblings. It mentions unique features like collapse_stories and opaque cursor pagination, providing context for when to use this tool over more specific ones.

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

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

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral details: returns news naming both companies, plus each ticker's own news for context, and unknown_tickers handling. This adds value beyond annotations, though no mention of rate limits or auth.

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 sentences with no wasteful words. The first sentence states the core action, the second provides context and edge-case handling. Efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the three output lists (cross-ticker, own news for each) and unknown_tickers behavior. With an output schema present, this is sufficient for an agent to understand the tool's 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?

Schema description coverage is 100%, so baseline is 3. The description does not add new semantic meaning beyond what the schema provides; it implicitly references parameters but gives no additional details or examples.

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 compares two tickers and returns cross-ticker read-across news plus each ticker's own news. It uses specific verbs ('Compare') and resources ('tickers'), and distinguishes from siblings like alphai_ticker_news which handles single tickers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use: for cross-ticker read-across (e.g., peer's print affecting another). It also covers handling of unknown tickers. However, it does not explicitly state when not to use or compare to alternatives, but the context is clear.

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

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

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral details: cursor-based pagination, inclusion of insider news by default, story collapse behavior, and the unknown_ticker flag for unrecognized symbols. This is consistent with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured paragraph of four sentences. It front-loads the core purpose ('Latest news for a single ticker'), then succinctly covers pagination, insider inclusion, story collapse, and the unknown_ticker flag. No redundant or extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, output schema, annotations), the description covers key aspects: purpose, pagination, response shape, parameter flags, and edge case (unknown ticker). It does not explicitly differentiate from all sibling tools, but the single-ticker focus and behavior details make it mostly complete.

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 has 100% description coverage for all parameters, so the schema already defines each parameter's meaning. The description restates some parameter behavior (e.g., include_insider default true, collapse_stories purpose) but adds no new semantic information 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 explicitly states 'Latest news for a single ticker' with an example 'AAPL', and the title 'Ticker news feed' reinforces this. It clearly distinguishes from similar tools like alphai_news_search by focusing on a single ticker.

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 context on when to use this tool (for a single ticker's news) and mentions pagination via cursor and the response shape matching alphai_news_search. It offers flags (include_insider, collapse_stories) to tailor usage, but lacks explicit guidance on when not to use it versus siblings like alphai_insider_news.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds filter behavior details (prefix vs substring matching) but does not go beyond what the schema and annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero wasted words. All information is front-loaded and essential.

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 complex environment of multiple sibling tools, the description fully explains what the tool does and its filtering options. Output schema exists to handle return values, so no need to describe them.

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 has 100% description coverage, so baseline is 3. The description adds value by clarifying the 'q' parameter's matching logic (prefix on ticker, substring on name) and explicitly mentioning sector filtering, which justifies a 4.

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 verb 'list', the resource 'supported tickers', and specifies scope including US stocks/ETFs, crypto, and foreign listings. Distinguishes from sibling tools like news and alerts, which have 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?

Mentions optional filters (query by ticker prefix or name substring, sector) but does not provide explicit guidance on when to use this tool versus alternatives, or when not to use it.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds behavioral detail about deduplication collapsing syndicated reprints and ranking by relevance, going 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?

Two sentences, front-loaded with purpose, no filler. Every sentence adds value.

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?

Full schema coverage, rich annotations, output schema exists. Description is sufficient for agent to understand tool's role and behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for each parameter. Description adds practical guidance ('Lower min_relevance to surface weaker movers'), enhancing beyond schema alone.

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?

Describes specific verb ('top news'), resource ('last 48h'), and ranking ('by AI-assigned relevance'). Distinguishes from siblings like alphai_news_search (search) and alphai_ticker_news (ticker-specific).

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?

Explicitly states when to use ('what's moving', 'what's the big story'). Provides guidance on adjusting min_relevance. No explicit when-not or alternatives, but sibling list provides implicit context.

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