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?

No annotations provided, so description carries full burden. It mentions creation but lacks details on permissions, side effects (e.g., whether duplicates are allowed, whether existing names can be reused), error handling, or rate limits. Insufficient 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?

Single sentence that is front-loaded with purpose and contains no redundant words. Efficiently conveys the core function.

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

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

Adequately describes what the tool does and its purpose, but omits information about return values (e.g., success confirmation or created universe details). For a creation tool, this is a notable gap.

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

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

Schema description coverage is 100%, with each parameter having a brief description. The tool description adds 'named set of tickers' which aligns but doesn't add significant new meaning 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 ('Create'), resource ('universe'), and context ('for scoping future scans'). It distinguishes from siblings like tickerbot_get_universe and tickerbot_list_universes, which retrieve or list existing 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 use before scans with 'for scoping future scans'. It doesn't explicitly state when not to use or mention alternatives, but the context is clear for the main use case.

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 are provided, so the description carries the burden of behavioral disclosure. It states it returns a time series but does not mention pagination behavior, ordering, or handling of missing data. The parameters (to, from, limit, cursor) are in the schema, but the description adds no behavioral context beyond that.

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 with the verb and object. No 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?

The tool has 7 parameters (all explained in schema) and no output schema. The description covers the core purpose but omits details about pagination (cursor, limit) and ordering of results. For a data retrieval tool, this leaves some context gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context that it is a time series for one signal and one ticker, clarifying that signal is a single column. However, it does not add specific parameter meanings beyond what the schema already provides (e.g., signal as 'column name').

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

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

The description clearly specifies the verb 'Get', the object 'time series of one signal for one ticker', and the chosen interval. It lists allowed intervals (1m, 1h, 1d, 1w), distinguishing it from siblings like tickerbot_get_ticker_history or tickerbot_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?

The description implies usage for retrieving historical signal data but provides no explicit guidance on when to use this tool vs alternatives like tickerbot_get_ticker_history or tickerbot_list_signal_events. No when-not or alternative recommendations are given.

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

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

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?

No annotations exist, so the description must disclose behavior. It mentions 'newest-first' ordering and optional filters but omits pagination behavior (e.g., cursor usage, rate limits, data freshness) or whether the operation is read-only. This leaves significant gaps for an agent.

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 sentence efficiently conveys purpose, scope, and optional filters without extraneous words. It is well-structured and front-loads the key action.

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

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

The description is adequate for a filtered-list tool with well-documented parameters, but it lacks details on return event structure (no output schema) and pagination mechanics. Given 6 parameters and no output schema, more context would improve completeness.

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 description adds limited value. It restates the event-kind filter and date window, but the schema already documents parameters like cursor and limit. The description does not clarify format or constraints 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 clearly states the verb 'Get', the resource 'discrete event log for one ticker', and specifies event kinds (splits, dividends, analyst rating changes) and sort order (newest-first). This distinguishes it from sibling tools like tickerbot_get_ticker_history (likely price data) and tickerbot_list_signal_events (different event types).

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 filtered event logs but provides no explicit comparison to sibling tools or guidelines on when not to use it. It lacks alternatives or exclusions, leaving the agent to infer 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 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?

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?

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 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?

No annotations provided, so description carries full burden. It indicates a read-only listing of caller's subscriptions but omits details like pagination behavior or authentication needs. Adequate but not enriched.

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?

Single sentence, 12 words, front-loaded with verb, no unnecessary information. Perfectly concise.

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

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

Sufficient for a simple list tool with pagination, but lacks description of output structure or any behavioral notes. Could mention 'returns active subscriptions without modification' but still functional.

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 both parameters with descriptions ('Page size.', 'Opaque cursor.'), so baseline 3. The description adds no additional meaning beyond what schema provides.

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

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

Clearly states the tool lists the caller's active webhook subscriptions, differentiating from sibling tools like tickerbot_delete_webhook and various subscribe tools by specifying 'rules created via the 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?

Implies usage for viewing personal webhook subscriptions, but does not explicitly exclude alternatives or state when not to use it. The context of sibling tools aids differentiation.

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 webhook registration, delivery options (own URL vs in-app), plan-gated cadence, and the change-triggering behavior. It lacks details on webhook payload format or failure handling, but covers essential 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, front-loaded with the main action, and uses concise phrasing. Every sentence adds value 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 5 parameters, no output schema, and no annotations, the description adequately explains the tool's purpose, key parameters, and usage scenario. It could cover return values or prerequisites but is sufficiently complete for a webhook registration 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 description adds value by explaining plan gating for cadence and the effect of omitting target_url. It does not repeat schema descriptions but provides extra context, especially for target_url and cadence.

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: registering a webhook that fires when scan query matches change. It distinguishes from sibling tools like tickerbot_subscribe_signal by explicitly mentioning scan queries and alerting on changes.

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 ('alert me when this happens' prompts) and explains when to omit target_url. However, it does not explicitly differentiate from other subscription tools or specify 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?

With no annotations, the description explains core behavior: webhook fires on boolean true or numeric condition. Mentions optional parameter effects. Lacks details on persistence, removal, or rate limits, but overall 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 concise sentences: first covers purpose and trigger logic, second covers key optional parameters. No superfluous 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?

Covers core logic and key optional parameters. Does not mention name, cadence, or universe, but schema descriptions for those are clear. Could add note on interaction between universe and ticker, but overall adequate.

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%. Description adds value by explaining that condition is required for numerics and ignored for booleans, and gives context for ticker and target_url beyond 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 registers a webhook and specifies the triggers (booleans true or numeric crossing condition). It distinguishes from sibling tools like tickerbot_subscribe_ticker by focusing on signal-based subscriptions.

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 optional parameters: ticker for restricting to one symbol, target_url for delivery method. Does not explicitly compare to alternatives but gives sufficient 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; description explains webhook registration, condition syntax, and delivery options but omits persistence, rate limits, or side effects.

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

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

Three sentences, front-loaded with purpose, uses backticks for parameters. Efficient with no waste.

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 condition format and delivery choice. Lacks return value description (no output schema) but sufficient for a creation tool with sibling tools for listing/deletion.

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 meaning beyond schema: explains condition as SQL WHERE fragment scoped to ticker, gives example, and clarifies target_url optionality. Schema coverage already 100%.

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', specifying verb and resource. Distinguishes from siblings like subscribe_scan and subscribe_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?

Provides context for optional target_url, but lacks explicit when-to-use vs alternatives or 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.