mcp-server

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

No annotations are provided, so the description carries full burden. It mentions saving and referencing but does not disclose persistence duration, overwrite behavior, authorization needs, or side effects like potential name conflicts.

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

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

The description is a single, concise sentence that front-loads the core purpose without extraneous 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 no output schema, the description should clarify return value (e.g., success indicator, ID of created signal) and conflict behavior. It lacks these details, making it adequate but 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 coverage is 100%; descriptions already explain 'SQL WHERE expression', 'Snake_case identifier', and 'optional description'. The description adds context about future referencing but does not significantly augment 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 (save a SQL WHERE expression) and the resource (named custom signal), distinguishing it from siblings like tickerbot_create_universe or listing tools. 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 implies usage for reusing filters in future scans but does not explicitly state when to use this tool versus alternatives (e.g., storing in a table vs. inline query). No when-not or exclusions are 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 full burden. It confirms a write operation but lacks details on authentication, idempotency, uniqueness constraints (only noted in schema), or side effects. The description adds minimal behavioral context beyond the action.

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

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

The description is a single sentence with no unnecessary words. It is front-loaded with the action and resource. Every word is purposeful.

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 (4 parameters, no output schema, no nested objects), the description is nearly complete. It could mention that the universe is used in scan scoping, which is implied but not explicit. However, the rich schema and sibling context make this minor omission acceptable.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any additional parameter-level meaning beyond what the schema already provides, so it meets but does not exceed 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 clearly states the action ('Create'), the resource ('a new universe'), and the purpose ('for scoping future scans'). It effectively distinguishes from sibling tools like tickerbot_get_universe and tickerbot_update_universe.

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 context (for scoping scans) but does not explicitly state when to use this tool versus alternatives like tickerbot_update_universe. No guidance on prerequisites or 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?

The description details cascade-safe behavior, conflict response (409 with referencing signals), and force option consequences. Without annotations, it adequately covers key behavioral traits.

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 concise sentences with no fluff. The first sentence states the purpose, followed by cascade behavior and force option. Front-loaded and 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?

Given the tool's complexity (delete with cascade check) and no output schema, the description is fairly complete. It covers plan requirement, default behavior, and error case. Missing explicit mention of irreversibility but implied.

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?

Both parameters are documented in the schema (100% coverage). The description adds value by explaining the force parameter's effect and default value, going 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 deletes one of the caller's custom signals, using a specific verb and resource. It distinguishes from sibling tools like create and update.

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 it (delete a custom signal) and provides context on cascade-safe behavior and force option. However, it does not explicitly mention alternative tools for modifying signals.

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?

Discloses destructive nature and side effect on webhooks (they will fail). No annotations provided, so description carries full burden. Missing details on permissions or reversibility, but adequate for a delete 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 with no fluff. Front-loaded purpose, followed by critical usage constraint. 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?

Sufficient for a simple delete tool with one required parameter. Covers constraints and side effects. Lacks description of return value or error handling, but not essential for selection/invocation.

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

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

Schema explains id is a universe slug. Description adds no new semantic detail about the parameter, only context that system slugs are invalid. With 100% schema coverage, baseline is 3.

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

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

Clearly states the tool deletes a universe and specifies that system universes cannot be deleted. Distinguishes from sibling tools like create_universe or update_universe.

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

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

Explicitly warns that system universes are not deletable and advises cleaning up webhooks first. Provides clear when-to-use and prerequisite information.

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 provided, so description bears full burden. 'Delete' implies destruction, but no details on irreversibility, effects, or required permissions. Minimal disclosure beyond the obvious.

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: first states purpose, second gives usage context. No fluff, efficiently communicates key info.

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 parameter, the description is adequate. It could mention return values or irreversibility, but is largely complete without 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?

Schema coverage is 100% with a good description for 'id' (looks like `wh_…`). The description does not add significant meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states 'Delete a webhook subscription by id' (specific verb+resource). It distinguishes from sibling tools like tickerbot_list_webhooks (listing) and tickerbot_create_custom_signal (creation).

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 says 'Use after listing webhooks when the user wants to remove an alert,' providing explicit context for when to use it. It does not explicitly state when not to use, 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?

No annotations provided, but description fully discloses behavior: flips to active, clears match-state, and is a no-op if already active. No contradictions.

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

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

Two concise sentences: first states primary action and effect, second provides usage guidance and edge-case behavior. 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?

Given simple parameter (id) and no output schema, description sufficiently covers behavior, use cases, and side effects for an agent 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?

Only one parameter 'id' with schema description 'Webhook id.' Description adds no further semantic detail, but schema coverage is 100%, so baseline score 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 re-enables a disabled webhook, flipping it to active and clearing match-state. It distinguishes from sibling tools like delete_webhook or test_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?

Explicitly says 'Use after fixing whatever caused auto-disable' and notes no-op on already-active webhooks. Does not name alternatives but 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 full burden for behavioral disclosure. It does not mention read-only nature, authentication, rate limits, or any side effects. The tool appears to be a simple query, but transparency is lacking.

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

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

The description is a single, clear sentence that is front-loaded and contains no unnecessary words. Every part serves to convey the tool's purpose.

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

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

Given the presence of optional parameters for pagination (cursor, limit) and time range (from, to), the description is too minimal. It fails to explain these important aspects, and there is no output schema to describe the return format.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds high-level context ('time series of one signal') but does not explain parameter details like pagination or time range beyond what the schema already provides.

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

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

The description uses a specific verb ('Get') and identifies the resource ('time series of one signal for one ticker at a chosen interval'). It clearly states the available interval options, distinguishing this tool from unrelated siblings like tickerbot_get_ticker_bars or tickerbot_list_signals_catalog.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any conditions or exclusions. It simply states what the tool does without usage 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?

No annotations present, so description carries full burden. It discloses sorting behavior (desc for numerics), page size limits, and defaults. Lacks mention of pagination mechanics or response format but is sufficient for a 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?

Two sentences, front-loaded with main purpose, then key details. Zero waste, easy to scan.

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 6 parameters (1 required) and no output schema, the description explains the core logic well. Could elaborate on pagination cursor or return structure, but overall covers essential usage.

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

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

Schema coverage is 100%, but the description adds meaningful context beyond schema: booleans need no condition, numeric condition syntax with examples, and sorting by value desc. This extra value justifies 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 clearly states the verb 'find' and resource 'tickers that match a single signal', with time context ('right now or past date'). It also distinguishes handling of booleans vs numerics, setting it apart from sibling tools like tickerbot_list_tickers or tickerbot_get_signal_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?

Provides clear guidance on when to use 'asof' and the condition requirement for numeric signals. However, it does not explicitly contrast with sibling tools or state when not to use this tool.

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 provided, so description carries full burden. Discloses return of full row and asof behavior, but does not mention any limitations (e.g., real-time latency) or error conditions. Adequate but not comprehensive.

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 front-loading the purpose and adding the asof usage. No fluff, 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 getter with two parameters and no output schema, the description sufficiently covers what the tool returns and how to use parameters. Could mention error handling, but overall complete enough.

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%, but description adds value by explaining 'every column on the schema' and case-insensitivity for ticker, which are not in schema. Enhances understanding beyond schema alone.

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

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

Clearly states 'Get the full current row for one ticker' with specific verb and resource. Distinguishes from siblings like tickerbot_get_ticker_events and tickerbot_get_ticker_history, but does not explicitly differentiate.

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?

Describes when to use the 'asof' parameter but lacks explicit guidance on when not to use this tool versus alternatives like tickerbot_get_ticker_history, which might be more appropriate for historical analysis.

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?

Description discloses ordering (oldest-first), bulk capability (up to 50 tickers), and back-fill behavior for sub-hour intervals. No annotations are provided, so description carries full burden. Lacks details on authorization, rate limits, or what happens with invalid tickers. Useful but not exhaustive.

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 with no filler. Front-loaded with purpose and key details (oldest-first, bulk). Every phrase 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?

Despite no output schema, description hints at response structure (bulk response keyed by symbol) and ordering. For a data retrieval tool, it adequately covers input behavior. Could mention return format (e.g., array of bars) but not essential.

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 of 3. Description briefly explains the intent of `asof` vs `before`+`limit` and notes interval behavior, but does not add significant meaning beyond schema descriptions for individual parameters.

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

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

Description clearly states the tool gets OHLCV bars for one or more symbols at a given interval, oldest-first. It differentiates from sibling tools that handle tickers, events, or signals, as no other sibling specifically retrieves bar data. The verb 'get' and resource 'ticker bars' are explicit.

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 guidance on when to use `asof` for a point-in-time bar versus `before`+`limit` for back-paging. Mentions coverage differences for intervals (1d/1h vs sub-hour). Does not explicitly state when not to use or list alternatives, but context is sufficient for most use cases.

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 provided, but description adds ordering (newest-first), merging of event types, optional filters, and back-paging mechanism. Adequate for a read-only 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 concise, front-loaded sentences with clear structure, 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?

No output schema, but description tells what is returned (merged events). For a data retrieval tool, this is reasonably complete. Could mention exact fields, but not required given sibling patterns.

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 all parameters with descriptions (100% coverage). Description restates some param info but adds context like merging and ordering. Baseline score of 3 is appropriate as no significant new meaning beyond 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?

Clearly states it gets corporate-event log for one ticker, listing specific event types (dividends, splits, insiders) and distinguishes from analyst rating changes which are not included.

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

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

Explicitly says when to use (for corporate events) and when not (analyst ratings are separate feed). Does not compare to all siblings but the most relevant one is mentioned.

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 exist, so the description carries the full burden. It describes that returns indicators, boolean flags, and fundamentals as of a past date, implying read-only behavior. It does not mention side effects, but none are expected for a historical query.

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 with no wasted words. The key concept 'Time-travel' is front-loaded. Every sentence adds value – describing the resource, return type, and use case.

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 only two required parameters and no output schema, the description adequately explains input (ticker + asof) and output (wide row with indicators, booleans, fundamentals). It is complete for its purpose, though lacks details on pagination or limits (unlikely needed).

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

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

Schema coverage is 100% with descriptions for both parameters (asof, ticker). The description adds 'as of a past date' for asof and 'full wide row' for output, but the schema already covers the parameter formats. No significant additional meaning beyond 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 (get) and resource (full wide row for one ticker as of past date). It clearly distinguishes from sibling tools like tickerbot_get_ticker (current data) and tickerbot_get_ticker_events (event-level history) by emphasizing time-travel and reconstruction use.

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

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

Explicitly states 'Use for backtests and reconstructions', providing clear context for when to use. It does not specify when not to use or compare to alternatives, but the stated purpose 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?

No annotations provided, so description carries full burden. It discloses ordering ('heaviest first') and behavior for non-ETFs. No mention of rate limits, auth, or other side effects. Adequate but not rich.

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

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

Two sentences plus a parenthetical note. Every sentence adds value, no filler. Efficient and front-loaded.

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

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

For a simple retrieval tool with 2 parameters and no output schema, the description covers key aspects: purpose, behavior for non-ETFs, ordering. Could mention read-only nature but implicit.

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

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

Schema coverage is 100%, and the description adds no new meaning beyond what the schema provides for parameters. 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?

Description clearly states verb and resource ('Get an ETF's constituent holdings and their weights') and distinguishes from sibling tool by explicitly noting reverse lookup is a different tool.

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 (ETF holdings) and explicitly excludes reverse lookup. It does not mention alternatives for non-ETF tickers beyond the empty holdings behavior.

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 key behavioral trait: non-ETF tickers yield is_etf=false and empty sectors. This is sufficient for a read-only lookup, though it omits details like authorization requirements.

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

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

Two concise sentences with zero waste. The key information is front-loaded: the tool's primary function and the critical edge case for non-ETFs.

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 single-parameter input and no output schema, the description fully covers the tool's behavior. It explains the return structure (sectors, is_etf) and handles the non-ETF scenario, making the tool's usage unambiguous.

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% (one parameter with schema description 'ETF symbol'). The tool description confirms the parameter's purpose but adds no new semantic detail beyond what the schema already provides. 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 verb ('Get') and resource ('ETF's sector allocation'), with explicit detail about output format (sector weights, heaviest first) and the edge case for non-ETFs. It stands apart from siblings like tickerbot_get_ticker_holdings by focusing on sector weights.

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 ETF sector data, and clarifies that non-ETFs return an empty sectors array. However, it does not explicitly contrast with similar siblings or provide when-not-to-use guidance.

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

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

With no annotations, the description adds the detail 'including its ticker list' which informs about response content. However, it does not disclose other behavioral traits like read-only nature, rate limits, or authentication requirements.

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

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

The description is a single sentence with no extraneous information. Every word adds value, making it highly concise and well-structured.

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

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

Given the tool's simplicity and lack of output schema, the description adequately hints at the return value ('including its ticker list'). It could be slightly more explicit about the output format, but it is sufficient for typical use.

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

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

Schema coverage is 100% and the parameter 'id' is described as 'Universe slug' in the schema. The description adds no new semantic meaning beyond what the schema provides, so a 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 verb 'Get', the resource 'universe', and the scope 'by slug, including its ticker list'. It effectively distinguishes itself from sibling tools like tickerbot_list_universes which likely returns a list without full details.

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

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

The description provides no guidance on when to use this tool versus alternatives such as tickerbot_list_universes. There is no mention of when-not-to-use or prerequisites.

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 implies a read operation ('fetch'), but does not explicitly state non-destructiveness or disclose any other behaviors like rate limits or data freshness. The scope info is helpful but incomplete.

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 with no wasted words. The first sentence front-loads the core purpose and output, the second provides important scope 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 the low complexity (simple fetch by ID), the description adequately covers the tool's behavior and scope. Lacks explicit mention of output format, but the mention of returned fields mitigates this.

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

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

With 100% schema coverage and a single parameter already described in the schema as 'Webhook id (looks like wh_…)', the description adds no new semantic information beyond stating it is used 'by id'.

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 'Fetch one webhook subscription by id' and specifies the returned data ('current state, match-set, schedule'). This distinguishes from sibling tools like tickerbot_list_webhooks which fetch all 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 provides context on account-scoping and authorization ('any key on the account can read any of the account's webhooks'). It does not explicitly contrast with sibling tools or state when not to use, but the purpose is clear enough.

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?

Discloses sorting (newest-first), cursor ignoring filters except limit, plan-gating, and history depth. No annotations provided, so description carries full burden. Misses rate limits or error handling details.

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?

Description is well-structured with purpose first, then constraints, paging, output fields. Slightly lengthy but no unnecessary 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?

Covers filtering, paging, plan requirement, history depth, and output fields (compensating for no output schema). Lacks default limit or error examples but is largely 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?

Schema coverage is 100%, but description adds value by explaining cursor behavior (ignores all filters except limit), required filter combination, and output fields. Exceeds baseline 3.

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 per-event analyst rating history (upgrades, downgrades, etc.) from an archive back to 2012. This distinguishes it from sibling tools like get_ticker_events or list_signal_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?

Describes plan requirement (Scale+), filter constraints (AND-combined, at least one required unless using cursor), and cursor behavior. Lacks explicit comparison to similar tools but provides strong usage 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?

The description notes 'newest-first' ordering, which is helpful. However, with no annotations, it fails to mention pagination behavior (though cursor/limit are in schema), rate limits, or that it's a read operation. Additional context like 'returns up to limit results' would improve 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?

A single, front-loaded sentence that efficiently conveys the core purpose and ordering. No fluff or redundant information.

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

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

For a list tool with 6 parameters and no output schema, the description is minimal. It explains the primary action but lacks details on return value structure, pagination semantics, or error cases. Additional context would be beneficial.

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?

All 6 parameters are described in the input schema, but the description adds no extra meaning beyond the schema's descriptions. It does not clarify how 'to', 'from', 'cursor', or 'limit' relate to the pagination or filtering logic.

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 'discrete firings of a boolean signal for one ticker' with 'newest-first' ordering, specifying the exact resource and ordering behavior. It distinguishes itself from sibling tools like tickerbot_get_ticker_events or tickerbot_list_signals_catalog.

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 use when needing historical firings of a boolean signal but provides no explicit guidance on when to prefer this over alternatives like tickerbot_get_signal_history or tickerbot_get_ticker_events. No exclusions or prerequisites are mentioned.

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 describes the listing operation as non-destructive and mentions both kinds of signals. However, it does not explicitly state pagination behavior or any potential side effects, relying partly on parameter descriptions.

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 purpose, and contains no 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?

Given no annotations, no output schema, and 100% schema coverage for parameters, the description adequately explains the tool's purpose and when to use it. It could mention pagination explicitly, but the parameter descriptions fill that gap. Overall, it is sufficient for agent invocation.

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

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

Schema coverage is 100%, so parameter descriptions already exist. The tool description does not add significant new meaning beyond what the schema provides for 'kind', 'limit', and 'cursor'. 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?

Description clearly states 'List the unified signal catalog' and distinguishes between built-in and custom signals. It also explains the use case: discovering available signals before composing a scan. This provides a specific verb and resource, and differentiates from siblings.

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

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

Description explicitly states to use it 'to discover what `q=` clauses and signal names are available before composing a scan.' This gives clear context on when to use the tool, though it does not provide explicit exclusions or alternatives 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 full burden. It implies read-only behavior by describing a list operation and provides useful context (built-in, no account restrictions). It could explicitly state it is a safe, non-destructive operation, but the current text is sufficient for an agent to infer safety.

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 concise sentences, front-loaded with the key information (slugs and their meaning). Every sentence serves a purpose: what the tool returns, how it is maintained, and how to use the results. 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 zero-parameter, no-output-schema tool, the description is complete. It tells the agent what the tool returns, the nature of the data, and how to use the output in other tools. No additional information is needed for correct invocation.

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

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

The input schema has zero parameters, so the description adds value by explaining what the output contains (the slugs and their meaning). It goes beyond the schema by describing the nature of the universes and their maintenance cycle.

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 built-in system universes ('top_10', 'top_100'), explains what they represent (most-actively-traded tickers by 30-day trailing dollar volume, rebalanced monthly), and differentiates from sibling tools like 'tickerbot_list_universes' (which likely lists user-created universes) by specifying 'system universes' and availability to every account.

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

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

Explicitly tells the agent when to use the slugs: 'as `universe` in scans/signals or `universe_id` when subscribing'. Also notes that these universes are 'available to every account regardless of plan', providing context for access control.

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 key behaviors: the tool lists active tickers, the `tickers` parameter overrides pagination and returns full rows, search orders by market_cap desc, and pagination is alphabetical via `cursor`. It does not mention rate limits or authentication, but the disclosed behaviors are sufficiently transparent for a listing 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 extremely concise—only two sentences. The first sentence quickly establishes purpose and scope, while the second covers usage modes and filters. No unnecessary words, and every sentence earns its place. It is well-structured and front-loaded.

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

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

Given no output schema, the description does not detail return format beyond 'full rows' for the `tickers` parameter. However, it covers the main filtering and pagination behaviors comprehensively. The schema descriptions are thorough for parameters. For a listing tool with a well-documented schema, this is largely complete, though output format 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?

The input schema already has 100% parameter coverage, so baseline is 3. The description adds value by explaining that the `tickers` parameter triggers bulk lookup and ignores pagination, that search orders results by market_cap desc, and that cursor pagination walks alphabetically. This context goes beyond the schema descriptions, enhancing understanding.

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, specifying the scope (~12,000 US equities + top 100 crypto). It distinguishes between usage modes (bulk lookup via `tickers` vs. paginated walk), making the purpose unambiguous and differentiating from sibling tools that deal with signals, universes, 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?

The description provides explicit guidance on when to use the `tickers` parameter for bulk lookup versus the `cursor` pagination for alphabetical walking. It lists supported filters but does not explicitly state when not to use this tool or compare it to other list tools. However, the context implies it is the primary ticker listing tool, so the guidance is clear enough.

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 full burden but only states the basic operation. It lacks details on pagination behavior, rate limits, or any side effects, which are important for a list 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 a single, efficient sentence with no wasted words, making it easy to parse.

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

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

The description is minimal and does not explain the return format or structure of the listed universes. While adequate for a simple tool, it leaves the agent guessing about output details.

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

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

Schema coverage is 100% and both parameters ('limit', 'cursor') are described in the schema. The description adds no additional meaning beyond what the schema provides.

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

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

The description clearly states the action ('list') and resource ('caller's saved universes'), distinguishing it from siblings like 'tickerbot_get_universe' and 'tickerbot_create_universe'.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. Usage is implied by the tool name and context, but no alternatives are discussed.

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 burden and excels: it states that only metadata is returned (status, attempt, response code, error), that the POST body is not stored, and that results are newest-first. This fully discloses behavioral traits.

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, no fluff. The first sentence states purpose and ordering, the second adds scope and limitation. 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?

Given no output schema, the description adequately explains what is returned and what is not. It mentions the use case. Could briefly mention pagination (limit/cursor) but schema already covers that. A minor gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add additional parameter-specific meaning beyond the schema, but it provides overall context (diagnosing failures) that indirectly helps. No extra parameter details needed.

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

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

The description clearly states the verb (list), resource (deliveries for a webhook), and context (newest-first, for diagnosing failures). The name matches well, and it is easily distinguishable from sibling tools like tickerbot_get_webhook and tickerbot_test_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 includes context for when to use it ('for diagnosing failures') but does not explicitly provide when-not-to-use or alternative tools. The sibling list implies alternatives, but explicit exclusion would be better.

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 exist, so the description carries full disclosure burden. It discloses ordering ('newest-first') and filtering capability. It is consistent with a read-only, non-destructive operation, which is appropriate. It could mention pagination, but the schema already captures limit/cursor.

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: first states primary purpose with key details (resource, scope, ordering), second adds filtering guidance. No extraneous words 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?

Given a simple list tool with no output schema and high schema coverage, the description adequately covers purpose, ordering, and filtering. It is complete enough for an agent to invoke 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% with descriptions for all three parameters. The description adds value by explicitly telling the agent to use the `status` parameter for filtering, which is helpful beyond the raw schema definition.

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

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

The description clearly states the verb 'List', the resource 'webhook subscriptions', and specifies scope ('caller's') and ordering ('newest-first'). It distinguishes from sibling tools like get_webhook and list_webhook_deliveries by focusing on subscriptions from subscribe tools.

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

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

The description implies the tool is for listing all webhook subscriptions and mentions filtering by status. While it doesn't explicitly exclude alternatives, the context of siblings (e.g., get_webhook for single) is clear enough for an agent to decide.

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 the query grammar is limited (no JOIN, GROUP BY, subqueries), mentions max length for q, and implies read-only behavior. It does not cover rate limits or auth, but for a query tool, this is sufficient.

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

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

The description is very concise, with two sentences plus a brief example and grammar note. It is front-loaded with the main action and contains no superfluous information. 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 complexity of 8 parameters and no output schema, the description covers the core functionality and query grammar well. It does not detail all parameters (e.g., cursor, fields, universe) but the schema descriptions for those are adequate. The description is sufficient for a skilled user to understand the tool's capabilities.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value by explaining the q grammar (flat WHERE, allowed operators, examples) and the asof parameter's purpose (historical scan). This goes beyond what the schema provides.

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

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

The description clearly states the tool runs a SQL WHERE clause against the ticker universe and returns matching tickers sorted by a chosen column. It distinguishes itself from sibling tools by its unique query capability and explains the grammar limitations, leaving no ambiguity about the tool's 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 explains when to use the tool (for scanning tickers with SQL-like queries, optionally with asof for historical data) and provides an example. While it does not explicitly state when not to use it or name alternatives, the sibling tools are distinct (e.g., signals, universes), so the usage 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?

No annotations provided, but the description discloses that it queries an archive (read-only), mentions plan gating, and lists return columns. Does not mention any destructive 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?

Front-loaded with key purpose and constraint. Contains several useful details but is not overly verbose. Could be slightly trimmed but remains effective.

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?

Tool is complex (SQL query, 8 params, no output schema) but description covers columns, examples, aggregation, and plan requirement. Lacks output schema but describes return fields adequately.

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

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

Schema has 100% coverage, but the description adds substantial value by explaining SQL WHERE clause usage, providing examples with ticker filtering and aggregation, and explaining defaults like 'order' column behavior.

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

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

The description clearly states the verb 'Search' and the resource 'news archive' with a specific date range (back to 2015). It distinguishes from sibling tools that focus on tickers, signals, universes, etc.

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 context: it's a SQL-based search on news archive, with a plan requirement (Scale+). Includes examples for filtering by ticker. Lacks explicit 'when not to use' or alternative tools.

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

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

With no annotations, the description carries full burden. It discloses the webhook fires on changes, delivery channels, and plan-gated cadence, but omits what the webhook POST data looks like, authentication needs, or idempotency 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, first clearly states main purpose. The second sentence covers multiple details compactly. Could be slightly more concise but is efficient overall.

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?

No output schema is provided, and the description does not explain what the function returns (e.g., webhook ID or status). For a subscription tool, return value is critical. Also lacks error handling or idempotency details.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining channel inference, required discord_url for discord, default name, and cadence limits, going beyond the schema descriptions.

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

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

The description uses a specific verb ('Register') and resource ('webhook that fires when matches for a scan query change'), clearly distinguishing it from siblings like tickerbot_subscribe_signal or tickerbot_subscribe_ticker.

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

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

Explicitly states use case ('satisfy alert me when this happens prompts') and explains delivery options and cadence constraints, but does not explicitly exclude use for other types of subscriptions.

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?

Describes trigger conditions (true/boolean, crossing condition/numeric) but lacks details on webhook lifecycle, authentication, or rate limits. With no annotations, disclosure is adequate but not thorough.

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 with no redundancy, front-loads core action and conditions, then lists options succinctly. 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?

Covers key aspects for a 9-param tool with 100% schema coverage. No output schema needed. Lacks behavioral details like idempotency or side effects, but sufficient for typical use.

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?

Adds value beyond schema by explaining condition usage for numerics vs booleans, channel inference, and omission defaults. Schema coverage is 100%, so baseline is 3; description raises 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?

Description clearly states it registers a webhook that fires on signal conditions, distinguishing it from sibling subscription tools like tickerbot_subscribe_scan and tickerbot_subscribe_ticker by specifying the signal-based trigger.

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 guidance on when to use (subscribe to signal events), how to restrict to a ticker, and how to set up delivery channels. Does not explicitly exclude alternative tools but context suffices.

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?

Discloses that condition is a SQL WHERE fragment and delivery endpoints. No annotations provided, so description carries full burden but omits potential warnings about validation, rate limits, or overwriting.

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-load main purpose, then elaborate on condition and channel. No wasted words, efficient structure.

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

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

Covers core functionality, condition, and channels well. Lacks output description and potential limits, but reasonable given no output schema and moderate parameter count.

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?

Adds significant meaning beyond schema descriptions by explaining condition as SQL fragment with example, and channel inference rules. Schema coverage is 100%, but general description enriches understanding.

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

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

Clearly states 'Register a webhook that fires when one ticker matches a condition' with a specific verb and resource. Distinguishes from siblings like tickerbot_subscribe_signal which likely subscribes to signals across tickers.

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

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

Provides explicit guidance on condition syntax and delivery channel options, including when to omit parameters. Lacks explicit when-to-use vs siblings like tickerbot_subscribe_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, the description fully discloses behavioral traits: synchronous, byte-identical body, test header, return outcome fields, one-shot, failure condition (400 if no target_url). Comprehensive.

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 with no wasted words. First sentence states core action and mode, second adds body details, third covers outcomes and edge cases. Front-loaded and 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?

Given no output schema, the description explains return values and covers behavior comprehensively: synchronous, one-shot, no retry, no auto-disable, error condition for missing target_url. Complete for a test 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?

Only one parameter (id) with 100% schema coverage. The description adds little beyond the schema's 'Webhook id.'; it implicitly ties the id to the target webhook but offers no additional syntax or format details.

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 combination (send a webhook.fired POST) and distinguishes it from sibling tools like tickerbot_delete_webhook or tickerbot_list_webhooks by focusing on testing.

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

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

The description clearly states the tool is for synchronous testing of a webhook, with failure behavior (no retry, no auto-disable). No explicit alternative is given, but the context makes it clear it's not for production fires.

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 provided, but description adds crucial context: recompilation of expression against live column whitelist, ownership restriction, and plan requirement. Fully discloses 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 main action, no wasted words. Highly concise and structured.

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

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

All parameters usefully described, ownership and plan requirement covered. No output schema needed for update tool. Complete for its complexity.

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

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

Schema coverage is 100%, baseline 3. Description adds value by explaining that providing 'expr' triggers recompilation and revalidation.

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

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

Description clearly states 'Edit one of the caller's custom signals' with specific verb and resource. It distinguishes from siblings like create and 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?

Explicitly states that it only applies to custom signals owned by the caller and requires 'Scale plan or above'. Provides clear context for when to use, but does not explicitly mention alternatives.

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 full burden. It discloses that only caller's universes can be updated and system universes are restricted. However, it omits details like return value, error conditions, or permission requirements.

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

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

The description is three short sentences, front-loaded with the main action, and each sentence adds necessary information 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?

The description covers main use cases and restrictions, but lacks information about return values or confirmation of success. Given no output schema, this gap is notable but not critical.

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

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

The input schema has 100% parameter description coverage. The description adds value by grouping parameters into functional categories (relabel, replace, adjust), explaining how they interact beyond the 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 clearly states the tool updates a caller's universe and specifies the update options (relabel, replace tickers, adjust subsets). It also notes system universes are excluded, distinguishing it from create/delete/sibling tools.

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

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

The description provides context on when to use add/remove vs tickers, and explicitly states system universes cannot be edited. However, it does not directly compare this tool to related tools like create_universe or delete_universe.

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