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

There are no annotations, so the description carries the full burden. It conveys the persistence and reusability of the signal ('reference by name in future scans'), which is valuable context beyond the schema. However, it doesn't disclose potential side effects (e.g., overwriting an existing signal with the same name) or any permissions required, leaving some transparency 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 a single, focused sentence that front-loads the core action ('Save...') and its purpose. Every word adds value, with no fluff 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's simplicity (3 parameters, no output schema, no annotations), the description is complete: it explains what is saved, how it is structured (SQL WHERE expression), and the key benefit (reusable by name in future scans). No critical information is missing for a create 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?

The schema provides 100% coverage with descriptions for all three parameters (`expr`, `name`, `description`), so the baseline is 3. The description does not add additional parameter details beyond what the schema already includes; it merely restates the role of `expr` as a SQL WHERE expression.

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: 'Save a SQL WHERE expression as a named custom signal' with a specific verb and resource. It distinguishes this from scanning directly by mentioning the signal can be referenced by name in future scans, differentiating it from sibling tools like `tickerbot_scan` and `tickerbot_update_custom_signal`.

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 use case: creating a persistent, named filter for future scans. It doesn't explicitly mention alternatives or exclusions, but the context is clear. Sibling tools like `tickerbot_update_custom_signal` and `tickerbot_delete_custom_signal` exist, yet the description sufficiently hints that this is for creating a reusable signal.

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?

With no annotations provided, the description carries the full burden but does not disclose any behavioral traits beyond the verb 'Create' implying mutation. It fails to mention idempotency, permissions, side effects, or what the response contains.

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 action, resource, and purpose with no unnecessary words.

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 there is no output schema and no annotations, the description is adequate for a simple create operation but doesn't explain return values, prerequisites, or potential errors. The purpose is clear, but behavioral and post-condition details are missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds minimal semantic value by clarifying that a universe is a 'named set of tickers,' which indirectly maps to the name and tickers parameters but doesn't go 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 a specific action ('Create a new universe') and defines the resource as a 'named set of tickers' with a clear purpose ('for scoping future scans'). This distinguishes it from sibling tools like update_universe or list_universes.

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 usage context (to create a universe for scoping scans) but does not explicitly mention when to use this tool instead of alternatives like update_universe or delete_universe. No exclusions or alternative guidance 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?

With no annotations provided, the description carries the full burden. It discloses the HTTP endpoint, the required trigger object, and trigger shapes, but it does not mention what side effects occur (e.g., webhook creation, idempotency, required authentication, or response format). This is a gap for a mutation tool.

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

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

The description is three sentences long, front-loaded with the core purpose, and tightly structured: endpoint, usage guidance, and trigger shapes. Every sentence carries essential information with no fluff.

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 input side is well covered: 8 parameters with 100% schema coverage, trigger shapes detailed, and channel inference noted. However, there is no output schema and the description does not mention return values, error behavior, or prerequisites (e.g., authentication), leaving the context incomplete for a create 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 the baseline is 3. The description exceeds this by detailing the exact trigger shapes for each type (e.g., scan {type:'scan', q, universe?}), which the schema's trigger property only vaguely references by saying 'see the tool description'. This adds meaningful parameter semantics 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 is 'the canonical webhook create — POST /v2/webhooks with an explicit trigger object' and enumerates the four trigger types (scan, ticker, signal, event). It also explicitly distinguishes itself from the 'subscribe tools above' as flat sugar, making the purpose and scope unambiguous.

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

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

It provides explicit usage guidance: 'use this form when composing the trigger programmatically or when a sugar door doesn't fit.' It also names the alternative subscribe tools, giving clear when-to-use vs. when-not-to-use context.

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?

With no annotations provided, the description fully carries the behavioral disclosure burden. It details cascade-safe deletion, the 409 conflict response listing referencing signals, the force option, and the consequence that existing references will break on next recompile — strong transparency for a destructive operation.

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

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

The description is three efficiently structured sentences: what it does, default safety behavior, and force behavior. Every sentence delivers necessary information with no redundancy.

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

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

For a simple two-parameter delete tool with no output schema, the description covers the essential behavior: target scope, conflict handling, force alternative, and plan availability. Minor lack of explicit success response details is acceptable and likely inferred from standard API conventions.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the real-world consequence of force: existing references will break on next recompile, which goes beyond the schema's simple 'skip the reference check' phrasing.

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

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

The description opens with 'Delete one of the caller's custom signals,' a specific verb-resource pair that clearly identifies the tool's scope and distinguishes it from sibling delete tools like tickerbot_delete_universe and tickerbot_delete_webhook.

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 clear the tool operates on the caller's own custom signals and notes it is available on every plan, providing actionable context. It does not explicitly name alternatives or edge cases where another tool should be used, but the scope is unambiguous.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals important side effects (webhooks referencing the universe will fail on next eval) and notes the ownership restriction. It does not explicitly state that deletion is irreversible, but 'delete' strongly implies that. Overall, it covers the key non-obvious behaviors.

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 unnecessary detail. It front-loads the primary action, then adds crucial exclusions and side effects. Every sentence earns its place, making it a model of concise, structured documentation.

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 one parameter, no output schema, and no annotations, the description provides all needed context: what it deletes, ownership scope, what cannot be deleted, and downstream impact. It references the cleanup action (webhooks) and is sufficiently complete for an agent to invoke it safely. The sibling list includes delete_webhook, so the guidance is actionable.

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 100% coverage for the single parameter (id as 'Universe slug'), so the baseline is 3. The description adds value by naming example system universes (top_10/top_100) that are invalid targets, thereby enriching the understanding of what the id accepts 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 action ('Delete one of the caller's universes'), specifies the resource (universe), and sets the scope (caller's own). It further distinguishes from related tools by noting system universes cannot be deleted, which makes the purpose unambiguous among siblings like update_universe and list_universes.

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

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

The description gives explicit constraints on when the tool should not be used (system universes) and provides a prerequisite (clean up webhooks first). It does not explicitly name alternative tools, but the context with siblings like tickerbot_delete_webhook makes the necessary follow-up actionable. This is clear guidance, though it stops short of a full 'when-to-use vs alternatives' comparison.

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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It states the deletion action but does not mention consequences like irreversibility, required permissions, or error handling. This is a significant gap for a destructive operation.

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 the action, then usage context. No redundant information, every word earns its place.

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

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

For a simple delete tool with one required parameter and no output schema, the description adequately covers what it does and when to use it. It lacks details on outcomes or failures, but given the tool's simplicity, it is 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 schema already describes the 'id' parameter as a webhook id with format `wh_…`, providing 100% coverage. The description adds no extra semantic value beyond confirming the id is used for deletion, so the 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 action (delete), the resource (webhook subscription), and the identifier (by id). It distinguishes from sibling tools like create, patch, and list webhooks by focusing on removal.

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

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

Provides explicit usage context: 'Use after listing webhooks when the user wants to remove an alert.' This tells the agent when to invoke this tool, though it does not explicitly name alternative tools 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions that the tool clears match-state and is a no-op on already-active webhooks, which gives important side-effect information. It does not cover permissions or reversibility, but for a simple enable operation, it is sufficiently transparent.

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 long, front-loading the core action and effect, then adding usage context. Every word earns its place; there is no fluff 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's simplicity (one parameter, no output schema), the description fully covers what the tool does, its behavioral effects, and when to use it. It is complete for an agent to understand and invoke the tool correctly.

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

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

The input schema covers 100% of the parameter with a description ('Webhook id.'). The tool description adds no additional meaning beyond what the schema already provides, so the 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 specific function: re-enabling a disabled webhook and flipping it to active while clearing match-state. This distinguishes it from sibling tools like create, patch, delete, or list webhooks. The verb 're-enable' and resource 'webhook' are specific and 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 clear when-to-use guidance ('Use after fixing whatever caused auto-disable') and a when-not-to-use note ('No-op on an already-active webhook'). However, it does not explicitly mention alternative tools for related operations, so it falls just short of a perfect score.

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?

No annotations are provided, so the description carries the full burden. It discloses pagination ('cursor-paged backward'), row output shape, transitions_only behavior, plan coverage ('All-time on every plan'), and limits (25 columns, 50 tickers). This goes well beyond minimal 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?

Three sentences, front-loaded with the core concept ('THE series primitive'), and each sentence adds distinct, non-redundant information: capability, limits/behavior, transitions, and replacement of older routes. No filler.

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?

Despite having 9 parameters and no output schema, the description covers all critical aspects for selection and invocation: data shape, limits, pagination, transitions mode, plan access, and relationship to deprecated routes. It is more than adequate for an agent to decide when and how to use it.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters combine (flat row per ticker per interval step) and illustrating the output shape with an example, but it largely reiterates schema details. This extra contextualization 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?

The description uses a specific verb+resource with defining characteristics: 'THE series primitive: cross-ticker, multi-column time series on one aligned grid.' It clearly distinguishes from siblings like get_ticker_history and get_ticker_bars by stating it replaces per-ticker history routes and looping asof snapshots.

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

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

It explicitly names when to use: 'Replaces looping asof snapshots per date, and replaces the sunset per-ticker history routes.' This directly addresses alternatives and gives a concrete use case for transitions_only, making the usage context unambiguous.

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?

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: support for historical queries via 'asof', sorting behavior for numerics, and the condition requirement for numerics. Missing details like pagination, error handling, or universe defaults, but this is adequate for a read/filter tool.

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 the core action, and no wasted words. Every sentence adds meaningful information about usage and behavior.

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

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

For a tool with 8 parameters and no output schema, the description covers core behaviors well: temporal queries, condition syntax, and sorting. It doesn't describe the output rows or mention the 'universe' parameter default, but the schema covers parameter details. Overall, it is adequate for someone to start using the tool correctly.

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

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

Schema covers 100% of parameters, so baseline is 3. The description adds significant value by giving concrete examples for 'condition' (e.g., '>70', '<=200'), explaining the 'asof' behavior, and noting sort order. This goes beyond the bare schema definitions.

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: 'Find tickers that match a single signal right now (or at a past moment...)'. It uses a specific verb ('Find') and resource ('tickers'), and the scope of matching one signal distinguishes it from broader tools like tickerbot_scan.

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

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

Provides clear context on how to use the tool, including the distinction between boolean and numeric signals, the need for a 'condition' for numerics, and the 'asof' parameter for past moments. However, it does not explicitly mention when to use this instead of alternatives like scanning or signal event listing.

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?

With no annotations provided, the description carries the burden. It clearly explains that the tool returns every column on the schema and gives concrete examples (rsi_14, above_sma_50, pe_ratio). It also details the asof behavior: date-only gives close of day, timestamp gives moment-in-time row. This is valuable context beyond the bare parameter descriptions, though it does not mention error handling or rate limits.

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 the main purpose and followed by a single clarifying detail about asof. Every word earns its place, with no filler or repetition. It is concise yet comprehensive for the tool's complexity.

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 no output schema, the description appropriately explains what the returned row contains by referencing the full schema and listing examples. It also covers the asof edge case. The tool is simple (2 parameters, no nested objects), and the description gives enough context for an agent to select and correctly invoke it. Minor omissions like not-found behavior are acceptable for a getter.

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% for both parameters, so the baseline is 3. The description adds a concrete example timestamp (2026-07-20T15:30:00Z) and rephrases the asof semantics, but does not materially extend what the schema already provides. The ticker parameter semantics (case-insensitive, crypto prefix) are fully covered in the schema, not in the description.

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

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

The description starts with a specific verb and resource: 'Get the full current row for one ticker', and further clarifies scope by listing column categories (price, indicators, boolean flags, fundamentals). This clearly distinguishes it from sibling tools like get_ticker_history or get_ticker_bars, which are not point-in-time row snapshots.

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 obtaining a complete row at current or historical moment, but does not explicitly say when to use this tool vs alternatives. For instance, it does not mention that get_ticker_history or get_series would be used for multi-row time series. While the context is clear, there are no explicit exclusions or alternates.

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?

With no annotations, the description carries the full behavioral burden. It discloses ordering (oldest-first), bulk response shape (keyed by symbol), back-paging semantics (before+limit), and interval coverage differences (1d/1h full history vs sub-hour back-fill). This far exceeds what the schema alone reveals.

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?

Three dense sentences, each with distinct operational guidance (bulk, point-in-time, coverage/paging). Front-loaded with the core purpose, no filler or repetition of schema 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?

For an 8-parameter tool with no output schema, the description covers the main usage modes and critical behavioral nuances. The schema fully documents every parameter, so the description's high-level context suffices; minor gaps like default limit or cursor mechanics remain in the schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that asof returns a single bar, before+limit enables back-paging, ticker supports up to 50 symbols, and 1d/1h have full coverage. This goes beyond the schema's per-param descriptions, earning 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?

The description opens with a specific verb+resource: 'Get OHLCV (open/high/low/close/volume) bars for one or more symbols at a given interval'. It clearly distinguishes this tool from siblings like get_ticker or get_ticker_history by focusing on OHLCV bars, bulk symbol support, and interval-based retrieval.

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

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

Provides clear usage guidance: comma-separated tickers for bulk, asof for point-in-time bars, before+limit for back-paging, and interval coverage differences. However, it does not explicitly name alternative tools or state when NOT to use this tool, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It reveals the tool's role as an 'honesty endpoint' and clarifies it reports coverage rather than filling gaps. It adds context about limitations and edge cases. A minor gap is that it doesn't state read-only or side-effect safety, but it's implied and the description is quite transparent.

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 tightly written sentences with front-loaded purpose. Every clause adds value, including the em-dash elaboration and the concrete examples. No filler or 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?

For a single-parameter tool with no output schema, the description sufficiently explains what the report returns (intervals, columns, start time, depth) and when to use it. It could be more explicit about the exact response format, but given the simplicity, it is very 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 already describes 'ticker' as a symbol, providing 100% coverage. The description adds no additional parameter-level detail, but it does tie the parameter to the tool's purpose. Given the schema is complete, a 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 tool produces a data-coverage report for one ticker, enumerating what it covers: intervals, columns, time range, and depth. This distinguishes it from siblings like get_ticker_bars or get_ticker_history.

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

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

It explicitly instructs when to use this tool: before assuming a data gap is an outage, to check if data was ever covered. It also provides examples of edge cases (sub-hour bars, fundamentals on non-equities), making the usage context very 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?

No annotations are provided, so the description carries the full burden. It discloses that it returns a point-in-time row with indicators, boolean flags, and the most-recent fundamentals known on that date, plus 'Unlimited depth on every plan'. This gives clear behavioral expectations beyond a basic read operation.

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 the core concept. Every sentence adds value: the first defines what is returned and distinguishes it from a series; the second clarifies alternative usage and plan access. No filler or redundant 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?

For a two-parameter read-only tool with no annotations or output schema, the description is notably complete. It conveys return contents, temporal semantics, and plan access, while also directing to alternatives. A concrete example of the returned row could further enhance completeness, but it is not essential for this simple tool.

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

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

Schema coverage is 100% with both parameters described. The description adds meaningful context by framing asof as a 'past date' and explaining that the row represents state 'as it stood' with 'most-recent fundamentals known on that date', enriching the temporal semantics 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 uses a specific verb 'Time-travel SNAPSHOT' and clearly identifies the resource as 'the full wide row for one ticker as it stood at a past date'. It explicitly distinguishes from sibling tools by noting 'one row, not a series' and pointing to tickerbot_get_series for series data.

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 when to use this snapshot tool and directs to an alternative for series data ('for a multi-column time SERIES use tickerbot_get_series'). This clearly differentiates it from sibling tools and clarifies selection criteria.

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?

With no annotations provided, the description takes on the full burden of behavioral disclosure. It discloses edge-case behavior: when ticker is not an ETF, `is_etf` is false and `holdings` is empty; `is_etf: true` with zero holdings indicates a real ETF whose data isn't ingested yet. This goes beyond what the schema specifies and helps the agent interpret unusual responses.

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

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

The description is compact and efficient: a single main sentence followed by two clarifying notes. The core action is front-loaded, and every clause adds value—edge cases and exclusions are included without fluff. It is exemplary in 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?

For a two-parameter read tool, the description is fairly complete: it states the main output, ordering, edge cases, and a key exclusion. It lacks an explicit return-structure description, but the absence of an output schema means the description still conveys enough for the agent to use the tool correctly. A dedicated section on fields within each holding could nudge this to 5, but the current coverage is solid.

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 complete descriptions for both parameters: ticker is an 'ETF symbol' and limit covers max, default, and truncation behavior. The description adds ordering context ('heaviest first') but does not add new parameter-level semantics beyond the schema. Since schema coverage is 100%, 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 opens with a specific verb+resource: 'Get an ETF's constituent holdings and their weights, heaviest first.' This clearly states what the tool does and distinguishes it from siblings like get_ticker or get_ticker_sectors. The parenthetical further clarifies that this is not for reverse lookups, reinforcing its unique purpose.

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

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

The description explicitly states when NOT to use this tool: 'The reverse lookup "which ETFs hold NVDA" is a scan filter on the etf_holders column, not this tool.' This provides an exclusion and a pointer to an alternative. However, it doesn't discuss other contexts, such as when to use get_ticker instead of get_ticker_holdings, so it stops short of full guidance.

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?

With no annotations, the description carries the full behavioral burden. It discloses key behaviors beyond the tool name: non-ETF tickers return is_etf=false with empty sectors, and is_etf=true with zero sectors means data isn't ingested yet. It does not cover all edge cases like invalid tickers, but the disclosed behavior is genuinely useful.

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 focused sentences: the first states the core function, the second covers important edge-case semantics. Every phrase earns its place with no redundancy or filler.

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

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

For a one-parameter, read-only tool with no output schema, the description sufficiently covers what the tool returns (sector weights, ordered heaviest first), the is_etf flag, and the distinction between non-ETFs and ETFs without ingested data. This is complete enough for an agent to select and invoke the tool correctly.

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

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

The schema already provides 100% coverage for the single parameter with description "ETF symbol." The tool description reinforces this by saying "ETF's sector allocation," but adds no additional parameter semantics, so the baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: "Get an ETF's sector allocation (sector weights, heaviest first)." It clearly differentiates this tool from sibling tools like get_ticker_holdings or get_ticker_coverage by focusing on sector-level data.

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 usage context is implied through the description: use this when you need sector weights for an ETF. However, it does not explicitly state when to prefer this over alternatives (e.g., get_ticker_holdings for holdings or get_ticker_coverage for coverage), so clear exclusion guidance is missing.

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?

No annotations are provided, but the description discloses that this is a read operation ('Get') and that it returns the ticker list. It does not go into details about error handling, permissions, or side effects, but for a simple get tool, this is adequate.

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 concise sentence that front-loads the verb and resource, with no wasted words. Every piece of information is 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 simple nature of the tool (one parameter, no output schema), the description covers the essential behavior—what it retrieves and the resource identifier key. It doesn't document edge cases or return details, but the tool is simple enough that this is 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 already has 100% coverage, with the id parameter described as 'Universe slug.' The description adds minimal meaning beyond that, but it correctly aligns with the parameter, maintaining 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 uses a specific verb 'Get' with a clear resource 'one universe by slug' and adds 'including its ticker list', which differentiates it from sibling list_universes and get_ticker. It is unambiguous about what the tool does.

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 when you have a specific universe slug and need its details, but it does not explicitly state when to use this over list_universes or other alternatives. Context is clear but not supported by explicit exclusions.

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?

With no annotations, the description carries the burden and provides meaningful behavioral context: the account-scoped read access ('any key on the account can read any of the account's webhooks') and the specific data returned (state, match-set, schedule). This is useful for a read operation, though it does not cover error handling or pagination (not applicable).

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 concise sentences deliver the core purpose and an important access detail without redundancy. Every word earns its place, making it highly 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 get-by-id tool with one parameter and no output schema, the description is quite complete: it covers what the tool does, what is returned, and the access scope. It could be slightly more explicit about the absence of list functionality, but overall it is sufficient.

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

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

Schema coverage is 100% with a clear description of the 'id' parameter. The tool description adds no additional parameter semantics beyond the schema, which already explains the format ('wh_…'). This meets 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 uses the specific verb 'Fetch' and clearly identifies the resource as 'one webhook subscription by id', including what will be returned ('current state, match-set, schedule'). This distinguishes it from siblings like list_webhooks (multiple) and create/patch/delete webhooks.

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 retrieving a single webhook by id and adds the account-scoped access context. However, it does not explicitly mention when not to use it (e.g., use list_webhooks for all webhooks), so it lacks clear exclusions but still provides clear context.

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?

With no annotations, the description carries the full burden and does an excellent job. It discloses row format and ordering, analyst payload history, case-sensitivity nuances between structured filters and q, aggregate behavior (truncated: true instead of pagination), join semantics, and the mandatory bound condition. This is far beyond a minimal description.

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

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

The description is long but information-dense, covering a complex 20-parameter tool. It is front-loaded with the core purpose and examples, then logically flows to row format, analyst specifics, q grammar, aggregation, join, and bounds. While every sentence earns its place, it could be tightened to improve scannability without losing critical details.

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

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

Given the tool's complexity (20 parameters, no output schema, no annotations), the description is remarkably complete. It explains the return row shape, the difference between default and opt-in kinds, analyst filter behavior, q usage, aggregation response (truncated: true), join=state behavior, and the essential bound requirement. This covers the vast majority of what an agent needs to correctly invoke 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful high-level semantics: it explains that q 'speaks the SQL grammar over exactly (ticker, ts, kind, payload jsonb)', describes aggregation with group_by/select/having, and clarifies the bound requirement across multiple parameters. This goes beyond the per-parameter schema descriptions, though it does not dive into individual parameter syntax.

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: 'THE events primitive — one timeline over every event log, cross-ticker: dividends, splits, insider transactions, and analyst actions'. It gives concrete examples ('all splits this month', 'every analyst action in my universe this week') and distinguishes it from siblings like list_signal_events by noting signal and news are opt-in kinds. The verb+resource+scope is specific and 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 clear context for when to use the tool: as the events primitive covering all event logs, with optional kinds (signal, news) and aggregate/join modes. It also gives a critical constraint: 'Requires at least one bound: a ticker scope, a time window, or firm/action — q alone is not a bound.' However, it does not explicitly name alternative tools or state when to prefer them over this one, so it falls short of a 5.

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

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

With no annotations provided, the description carries the burden of explaining behavior. It does this well by detailing the difference between state windows (null ended_at while active, prices at both ends) and event point fires (started_at=ended_at), and clarifies the meaning of from/to. It does not cover merge_gap_seconds or pagination behavior beyond what the schema already describes, but the core behavior is well disclosed.

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 paragraph, front-loaded with the core purpose, and each sentence adds value. It is slightly longer than necessary but packs domain-specific details (state vs event, example query) without redundancy.

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

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

Given there is no output schema, the description does a good job explaining the row structure (started_at, ended_at, prices). It also covers the main use cases and exclusions. It does not explicitly list every return field, but the essential shape is conveyed. The tool is complex enough that a bit more detail on paging or merge behavior could be useful, but the description is largely sufficient.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context around from/to with the example but does not provide additional semantics beyond what the schema already states for each parameter. It reinforces the 'built-in booleans only' constraint for signal, but this is also implied in the description's first sentence.

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 it lists 'Occurrence SPANS of a boolean signal for one ticker, newest-first,' which is a specific verb+resource+scope. It distinguishes itself from siblings by explicitly contrasting state vs event flags and referencing tickerbot_get_series for non-boolean signals.

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

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

Provides explicit when-to-use guidance: 'Built-in booleans only — numerics and custom signals have no precomputed spans (use tickerbot_get_series).' Also gives a concrete example for date filtering ('Golden crosses in June' is from=2026-06-01&to=2026-06-30), making usage 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the output composition (built-in plus caller's custom signals) and enumerates the metadata fields included for built-in rows, which are beyond what the schema provides. It also indicates scoping to the caller's custom signals.

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 the primary purpose, followed by valuable detail on output content and intended use. Every sentence earns its place with no redundancy or fluff.

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

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

For a read-only listing tool with no output schema, the description explains what the response contains (including metadata fields) and when to use it. Parameters are fully covered by the schema, so the description is nearly complete; a brief note on pagination defaults could push it to a 5, but that is already in the schema.

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 schema already thoroughly documents all three parameters. The description adds the connection to 'q= clauses and signal names' but does not elaborate on limit/cursor behavior beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the action ('List') and the resource ('the unified signal catalog'), and distinguishes it from sibling tools by specifying built-in vs custom signals. It is specific and 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 an explicit use case: 'Use to discover what q= clauses and signal names are available before composing a scan.' It does not mention alternatives or exclusions, but 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.

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the universes are built-in, rebalanced monthly, and based on 30-day trailing dollar volume, plus availability to all accounts. This provides useful context beyond mere listing, though it doesn't specify response format or potential limitations, which is acceptable for a simple read operation.

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 the core action, and every clause adds value: what is listed, examples, definition, availability, and usage. There is no wasted wording or 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?

For a parameterless list tool with no output schema, the description is adequately complete. It explains what the universes are, why they exist, and how to use the resulting slugs. It doesn't describe the exact response shape, but for a simple list operation the expectation is straightforward.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly notes the slugs but doesn't need to add parameter details since none exist. The schema already confirms an empty object, so the description provides sufficient context for how to use the returned slugs.

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 'List the built-in system universes' with specific slugs and their definition, distinguishing it from sibling tools like tickerbot_list_universes which likely handles all universes. The verb and resource are explicit and 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 when to use this tool: to get system universe slugs that can be used in scans/signals or subscriptions. It notes availability to all accounts, implying it is the go-to for built-in universes. It doesn't explicitly mention alternatives like list_universes for custom universes, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the universe composition, the distinct behavior of the `tickers` parameter (returns full rows, ignores pagination), and the pagination mechanism. It does not mention rate limits, return format, or what 'active' means, but these are partially covered elsewhere and the description adds substantial context.

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

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

The description is three sentences long, front-loaded with the primary purpose, and each sentence adds distinct value: scope, bulk vs paginated behavior, and filter list. There is no fluff or redundancy, 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 complex listing tool with 10 optional parameters and no output schema, the description is quite complete: it explains universe content, two usage modes, pagination, and filters. It does not explicitly describe the response structure or error behavior, but these are often left implicit, and the overall context is sufficient for an agent to invoke the tool correctly.

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

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

The schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining the universe scope, the bulk-lookup mode behavior, and the existence of filters like search, asset_type, exchange, sector, and min_market_cap. This helps the agent understand parameter interplay without reading every schema detail.

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 lists active tickers from the Tickerbot universe, specifies the exact scope (~14,500 US equities, US Treasury curve, Fed policy rates, FX, metals, crypto under X:), and distinguishes this from a bulk lookup mode via the `tickers` parameter. It is a specific verb+resource+scope statement that differentiates it from sibling tools like get_ticker (singular) and list_universes.

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 usage context: 'Use `tickers` for bulk lookup of named symbols... otherwise walks the universe alphabetically with `cursor` pagination.' It also mentions supported filters. However, it does not explicitly compare to alternative sibling tools such as get_ticker for single-symbol lookups, so exclusions are not stated.

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?

No annotations are provided, so the description carries the burden. It adds useful behavioral context: each row carries a 'system: true|false' flag, and it implies a read-only listing operation. It does not disclose pagination behavior or auth requirements, but for a list tool these are less critical.

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 the core purpose, and every clause carries useful information. 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's simplicity (3 optional params, no output schema), the description is nearly complete: it explains purpose, filtering options, and a key output field. It doesn't explain pagination, but that is covered by the schema's 'cursor' and 'limit' descriptions. Overall, sufficient for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the semantics of the 'owner' parameter (defaults, meaning of 'me/system/all') and drawing an analogy to the signals catalog's 'kind'. This goes beyond the schema descriptions, justifying 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?

The description clearly states the tool's function: 'List universes — your saved ones and/or the built-in system universes (top_10, top_100).' It uses a specific verb ('List') and resource ('universes'), and explicitly defines the scope, distinguishing it from sibling list_system_universes by covering both owner and system universes.

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 how to filter using the 'owner' parameter ('me', 'system', 'all') and notes the default. However, it does not mention alternatives like tickerbot_list_system_universes, nor when to prefer one over the other. This is a clear omission given the sibling tool exists.

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?

With no annotations provided, the description carries the full burden and does so excellently. It discloses the return shape ('Returns metadata only (status, attempt, response code, error)'), a critical limitation ('the POST body is not stored'), and ordering behavior ('newest-first'). This goes beyond what the schema provides and gives the agent essential expectations.

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 the main function and purpose, then adds a valuable limitation. Every word earns its place, and no redundant information is present.

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

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

For a read-only listing tool with a comprehensive schema, the description covers all essential context: purpose, scope, ordering, use case, and return limitations. Since there is no output schema, the explicit mention of metadata fields (status, attempt, response code, error) is particularly helpful. The description and schema together fully equip an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, with detailed parameter descriptions (time formats for from/to, limit default, cursor opacity, status enum). The description adds no parameter-specific details, but the schema already documents them thoroughly, so 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 'List recent deliveries (pings and fires) for a webhook, newest-first' with a specific verb and resource, plus a use case ('for diagnosing failures'). This differentiates it from sibling tools like get_webhook (config) and test_webhook (send test ping), and from list_webhooks which lists webhooks themselves.

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 'for diagnosing failures' provides a clear context for when to use this tool. It does not explicitly name alternatives or exclusions, but it implies this is the tool for inspecting delivery history. It could be improved by explicitly distinguishing from test_webhook, but the guidance is sufficient.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context (caller's scope, newest-first ordering) but does not explicitly state that the operation is read-only or describe return format/pagination behavior. The verb 'List' implies safety, but explicit confirmation is absent.

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 the core purpose and a targeted usage tip. Every word earns its place; no fluff 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?

For a simple list tool with no output schema, the description covers scope, ordering, and filtering. It does not explain the response structure or pagination beyond what the schema provides, but the essential information for invoking the tool correctly is present. Slight gap in return value details, though acceptable 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?

Schema description coverage is 100%, so all parameters are already documented. The description adds a mention of filtering by 'status' but provides no additional syntax or semantics beyond the schema. It reinforces existing information without expanding on parameter meaning.

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

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

The description clearly states the action ('List'), the resource ('the caller's webhook subscriptions'), and a differentiator ('newest-first'). It also distinguishes from siblings like 'tickerbot_list_webhook_deliveries' and 'tickerbot_get_webhook' by focusing on subscriptions overview.

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

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

The description gives clear context for when to use the tool and specifically instructs how to use the 'status' parameter to filter. However, it does not explicitly mention when to prefer this over related tools (e.g., get_webhook for a single subscription or list_webhook_deliveries for delivery logs).

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?

With no annotations provided, the description carries the full burden. It discloses that `enabled` toggles without losing match-state, that trigger/channel are immutable by design, and that unknown fields return 400 rather than being silently ignored – all substantive behavioral details not visible in the schema.

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?

Three sentences: a front-loaded purpose, an explicit immutability caveat, and an error-behavior note. Every sentence earns its place with no redundancy.

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

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

For a patch tool with no annotations and no output schema, the description covers purpose, editable fields, immutable constraints, and error behavior. It does not explicitly describe the response payload or state partial-update semantics (omitted fields unchanged), which is a minor gap given the otherwise rich 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% with each parameter described, so the baseline is 3. The description restates the editable fields and adds a minor nuance about `enabled` preserving match-state, but does not materially enhance parameter semantics 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 opens with 'Edit a webhook in place' – a specific verb and resource – and enumerates the editable fields (`name`, `cadence`, `target_url`, `enabled`). This clearly distinguishes it from sibling tools like `tickerbot_create_webhook` and `tickerbot_delete_webhook` by signaling in-place 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?

It explicitly states that trigger and channel are immutable and directs users to delete and re-create for those changes. It also points to `tickerbot_enable_webhook` as the alternative for re-enabling with match-state clearing, giving clear when-to-use vs alternatives guidance.

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?

With no annotations, the description takes on the transparency burden. It reveals key behavioral constraints: the flat WHERE grammar, no JOIN/subqueries, unlimited asof depth, and the row-vs-aggregate output modes. It does not mention read-only implications, pagination, or error handling, but the stated limits give substantial insight beyond the schema.

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

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

The description is dense but every sentence earns its place: it opens with the core action, then explains output modes and grammar constraints, and ends with a practical example. No filler or redundancy; it is appropriately sized for the tool's complexity.

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

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

For a 12-parameter scan tool with no output schema, the description covers the essential conceptual model: row mode, aggregate mode, the query grammar, and a representative example. It does not spell out default row projections or pagination details, but those are sufficiently documented in the input schema, so only a minor gap remains in return-value clarity.

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

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

The input schema already describes all parameters in detail (100% coverage), so the baseline is 3. The description adds valuable context by explaining the q grammar (AND/OR/NOT, comparison operators, literals) and demonstrating group_by rollups with examples, which deepens understanding beyond the schema's short parameter descriptions.

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

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

The description uses a specific verb+resource ('Run a SQL WHERE clause against the live ticker universe') and clearly distinguishes this tool from siblings by explaining its filtering and aggregation power. It also provides a concrete example, making the purpose unmistakable.

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

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

It clearly conveys when to use the tool: for arbitrary SQL-like filtering and aggregations over the ticker universe, with a past-moment option. However, it doesn't explicitly name alternative tools (e.g., list_tickers, get_ticker) or state when NOT to use this in favor of those, so it stops short of full exclusionary guidance.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It explains the archive depth, available columns, filter patterns, and aggregation support. It doesn't cover pagination or rate limits, but the schema covers cursor/limit, and the read-only nature is 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 reasonably concise, with the main purpose front-loaded and only essential details included. The column list and examples are useful but make it slightly dense; still, every sentence earns its place.

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

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

Given the tool's complexity (9 parameters, no output schema), the description covers the primary use cases well with examples and column details. It doesn't explain every parameter, but the schema fills that gap. It lacks explicit return-format info, but the column list compensates.

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

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

The schema has 100% coverage of parameters, so the baseline is 3. The description adds meaning beyond the schema by explaining the SQL WHERE clause for q, providing example syntax, and mentioning group_by/having behavior, thus adding value.

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

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

The description clearly states 'Search the news archive (back to 2015) with a SQL WHERE clause.' This uses a specific verb and resource, and distinguishes the tool from sibling tools focused on tickers, signals, or webhooks.

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

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

It provides clear context on usage, including availability on every plan, SQL syntax, example queries, and aggregation support. It doesn't explicitly say when not to use this tool versus alternatives, but the description makes the use case 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?

With no annotations provided, the description carries the full burden and does an exceptional job. It discloses the delivery payload structure ('events.fired' with an events array), latency expectations (analyst ≤1h, corporate daily), the need for paid plans (webhook slots), and the composable filter semantics. This is rich, non-obvious behavioral context that goes well beyond what the name or schema alone would convey.

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

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

The description is dense but every sentence earns its place: it states the core purpose, explains the two filters with concrete examples, notes the paid plan requirement, describes the delivery payload, and gives a latency caveat. There is no fluff or repetition; it is structured to front-load the most important information (what and when) before finer details.

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

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

For a create-operation tool with 10 parameters and no output schema, the description covers most essential context: purpose, event types, filter usage, delivery format, latency, and pricing. The only notable gap is that it does not describe what the tool returns upon success (e.g., a webhook ID or confirmation), which would be helpful given the lack of an output schema.

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 describes all 10 parameters (100% coverage), so the baseline is 3. The description adds meaning by explaining the conceptual distinction between q (ticker state) and event_q (event content), and why kinds is a comma-list string rather than an enum (to allow multi-kind values). This clarifies design rationale and helps the agent form correct queries, raising the score above baseline.

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

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

The description opens with 'Create an event-trigger webhook: fires when NEW events land', which clearly states the specific verb (create), resource (event-trigger webhook), and behavior (fires on new events). It enumerates event kinds (dividends, splits, insider filings, analyst actions) and includes examples, making it unmistakable what the tool does and how it differs from generic webhook creation tools like tickerbot_create_webhook.

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 context for when to use this tool (event-driven notifications for specific corporate events) and hints at an exclusion by contrasting latency: 'NOT sub-minute like state webhooks'. However, it does not explicitly name sibling alternatives (e.g., tickerbot_subscribe_ticker) or state when not to use it, so it stops short of a fully explicit when/when-not guide.

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?

With no annotations, the description carries the full burden. It discloses the trigger condition (matches change), default cadence (realtime/1m), throttling options (hourly or nyse_open), and delivery behavior (POST to target_url, Discord embed to discord_url, or in-app dashboard). It does not cover failure modes or auth details, but the main behavioral contract is clearly explained.

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

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

The description is three sentences and front-loaded with the core purpose. Each sentence earns its place: the first defines the action, the second explains delivery options, the third covers cadence and the common use case. It is compact without losing necessary context.

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 this is an 8-parameter tool with no output schema, the description provides solid coverage of the main delivery modes (webhook, Discord, in-app) and cadence settings. However, it omits the mobile_push/device_id path and does not hint at what the response looks like, though those are schema-described and arguably secondary.

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

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

The input schema already covers 100% of parameters, giving baseline 3. The description adds value by explaining parameter relationships: 'Pass `target_url` for an https POST, or `channel:"discord"` + `discord_url` to post an embed to Discord; omit for in-app delivery.' This clarifies how channel, target_url, and discord_url interact beyond individual schema descriptions.

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

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

The description opens with 'Register a webhook that fires when matches for a scan query change,' which clearly states the verb (register), resource (webhook), and specific trigger condition (matches for a scan query change). This distinguishes it from sibling tools like tickerbot_scan or tickerbot_subscribe_ticker, making the purpose unmistakable.

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

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

The final sentence provides explicit when-to-use guidance: 'Use to satisfy "alert me when this happens" prompts.' It also clarifies delivery-channel choices (webhook, Discord, in-app) but does not explicitly mention alternatives or when not to use this tool, so it falls just short of full exclusion guidance.

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?

With no annotations, the description carries the burden of behavioral disclosure. It explains exactly when the webhook fires (on true transition for booleans, on condition crossing for numerics) and how delivery routing works (webhook POST, Discord, in-app). It does not mention cadence throttling or lifecycle management, but the core behavior is transparent enough for safe use.

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 the core trigger behavior, then concise usage guidance. Every clause adds useful information with no filler or repetition of schema details.

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

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

Despite 10 parameters no output schema, the description covers the decision-critical aspects: trigger conditions, scope control, and channel routing combinations. The schema handles per-field details and enum values. Missing some context about subscription lifecycle and cadence effects, but the description is sufficient for a competent agent to select and invoke the tool correctly.

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

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

The schema covers 100% of parameters with descriptions, so baseline is 3. The description adds valuable cross-parameter meaning: it explains that ticker is optional and omitting it watches the whole universe, that target_url maps to webhook, and that discord_url pairs with channel:'discord'. This goes beyond the schema's per-field text and clarifies the relationship between channel and delivery fields.

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

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

The description opens with a specific verb ('Register a webhook') and clearly states the resource (signal subscriptions) and the trigger semantics (booleans turning true, numerics crossing a condition). It differentiates from sibling tools like subscribe_ticker, subscribe_scan, and create_webhook by focusing on signal-based conditional notifications.

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

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

The description gives clear usage direction: how to scope with optional ticker, how to choose delivery (target_url for webhook, discord_url for Discord, omit for in-app). It does not explicitly name alternative tools or say when not to use this tool, but the stated options and constraints provide sufficient guidance for selecting and invoking correctly.

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?

With no annotations, the description carries the transparency burden. It discloses the core behavior: the webhook fires when the condition matches, and it explains how POST/Discord/in-app delivery works. It does not cover webhook lifecycle (e.g., persistence, cancellation, failure handling) or mention cadence, but the schema covers cadence. The description adds useful context on channel selection.

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: purpose first, then usage details. It is front-loaded, uses concrete examples, and avoids unnecessary words. 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?

For an 8-parameter subscription tool with no output schema and no annotations, the description covers the core use case well: condition, channel selection, and delivery destination. It omits some details (mobile_push, device_id, cadence) but those are all described in the schema. The description provides enough context for an agent to select and call 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?

Schema coverage is 100%, providing baseline 3. The description adds value beyond schema by giving a concrete SQL condition example and explaining how to configure delivery channel (target_url for HTTPS POST, discord_url for Discord, omit for in-app). It does not cover all parameters, but the schema descriptions are sufficient.

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: 'Register a webhook that fires when one ticker matches a condition.' It clearly scopes to a single ticker and a condition-based trigger, differentiating it from sibling subscription tools like subscribe_signal or subscribe_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?

The description provides context on when to use the tool: for ticker-specific condition alerts. It explains the condition syntax, delivery channel options, and how to choose between webhook, Discord, or in-app. It does not explicitly name alternative tools or exclusions, but the scoping language ('one ticker', 'scoped to that ticker') implies it's for per-ticker conditions.

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?

With no annotations, the description carries the full burden and exceeds expectations. It discloses synchronous execution, byte-identical body/signing, X-Tickerbot-Test header, return fields, one-shot behavior (no retries, no auto-disable), and a 400 error for missing target_url.

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 yet information-dense. Every sentence contributes unique value: core action, body/signing details, return fields, one-shot semantics, and error condition. No fluff 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?

The tool is complex (test webhook) but the description covers all essential aspects: request behavior, response format, error conditions, and side effects. With no output schema, it explicitly lists return fields. Complete and self-contained.

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 single parameter 'id' is fully described in the schema (100% coverage). The description does not add parameter-specific syntax or format details, but baselines at 3 since the schema already handles it.

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

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

The description clearly states the action: 'Send a real-shape `webhook.fired` POST to the webhook's target_url synchronously, right now.' This specifies a unique verb+resource+scope, distinguishing it from sibling webhook management tools like create, patch, list, or delete.

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 context on when to use the tool (to test a webhook) and describes behavior like one-shot, no retries, and failure conditions. It does not explicitly contrast with alternatives, but the purpose is self-evident among siblings.

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?

No annotations are provided, so the description carries the full burden. It discloses recompilation against the live column whitelist when expr is supplied, the 409 conflict behavior for renaming, read-only status of built-in signals, and ownership restrictions. This is rich, non-obvious behavioral information that goes far beyond a basic 'update signal' statement.

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

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

The description is three sentences, all dense with relevant information. It front-loads the core purpose and then adds critical constraints in a structured order. There is no filler or repetition of schema details.

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

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

For an update tool with no output schema and no annotations, the description covers the key behavioral aspects: valid targets, ownership, conflict conditions, and plan availability. It doesn't describe the success response or any pagination/return format, but those are less critical for a patch operation. The combination of schema and description leaves few unanswered questions for the agent.

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 each parameter described, so the baseline is 3. The description adds value by stating that expr, description, and new_name can be supplied 'in any combination,' clarifying optionality beyond the single required 'name' parameter. It also explains the recompilation consequence of providing expr, which is not in 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 opens with a clear verb and resource: 'Edit one of the caller's custom signals.' It further specifies the editable fields (expr, description, new_name) and distinguishes from create/delete operations. Sibling tools include create_custom_signal and delete_custom_signal, making this unambiguously the update operation.

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

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

The description provides essential usage context: only custom signals owned by the caller can be patched, and built-in signals are read-only. It also flags a specific conflict scenario (renaming refused with 409 if referenced by other signals). While it doesn't explicitly name alternatives like 'use create_custom_signal for new signals,' the positioning among siblings and the ownership constraints give clear guidance.

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?

With no annotations, the description carries the burden of behavioral disclosure. It reveals that add/remove adjust subsets without replacing the whole list, that tickers replaces entirely, and that system universes cannot be edited. It does not mention return values or failure modes, but covers the most critical 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?

Two sentences, front-loaded with the action, and every clause adds value. No wasted words.

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 mutation tool with no output schema and no annotations, the description covers all parameter modes and the key restriction on system universes. It doesn't describe the response or partial-update semantics, but the scope is well covered for an update 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 coverage is 100%, so the schema already documents parameters. The description adds meaning by explaining how parameters relate: name/description relabel, tickers replace the whole list, add/remove adjust subsets. This provides operational insight beyond individual field descriptions.

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

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

The description clearly states the tool's function with a specific verb ('Update') and resource ('one of the caller's universes'), and distinguishes it from sibling tools by noting system universes cannot be edited. This leaves no ambiguity about what the tool does.

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

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

It explains the different update modes (relabel via name/description, replace via tickers, adjust via add/remove) and explicitly states system universes are off-limits. While it doesn't name create_universe as an alternative, the 'Update' wording implies existing universes, providing clear context.

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