TickerDB

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

The description discloses duplicate skipping (consistent with idempotentHint), the plan's watchlist_limit causing partial rejection, and advises verifying the response's confirmed tickers. No contradiction with annotations; it adds context beyond the structured hints.

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

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

The description is concise and front-loaded, with each sentence adding unique value: purpose, duplicate handling, usage trigger, limit caveat, and response verification. No filler or redundant repetition.

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

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

For a single-parameter tool with an output schema, the description covers usage conditions, edge cases (duplicates, limit), and expected response handling. It also references get_account for the watchlist limit, making it fully actionable for an agent.

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

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

The schema already fully documents the single 'tickers' parameter with an example, so the parameter semantics are well covered. The description adds behavioral context about duplicates and limits but does not introduce new meaning about the parameter itself, so baseline 3 is appropriate.

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

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

The description clearly states 'Add tickers to the user's saved watchlist' with a specific verb and resource, distinguishing it from siblings like remove_from_watchlist and get_watchlist. It also specifies duplicate behavior, adding further clarity.

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 instructs when to call: only when the user explicitly asks to track, save, or watch a ticker, and warns against adding just because tickers came up in conversation. It also references get_account for the watchlist limit, showing awareness of alternative tools and 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description goes beyond by specifying conditional response behavior: scheduled_tier and scheduled_change_at are returned only when a plan change is pending, and credit_balance appears only for pay-per-use accounts. This adds value beyond the annotations.

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

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

The description is three sentences: the first states the main purpose, the second lists response fields, and the third adds conditional details. It is front-loaded, well-organized, and every sentence provides new 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?

With an output schema already present and zero parameters, the description covers all necessary aspects: the tool's action, the full set of returned fields, and conditional behaviors. There are no significant gaps for this simple, read-only tool.

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

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

The tool has zero parameters, so there are no parameter meanings to clarify. The description appropriately focuses on the response structure. Given the empty schema, the baseline of 4 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 states a specific verb ('Get') and resource ('account details') and enumerates the exact content categories (plan tier, credit limits, usage). This clearly distinguishes it from sibling get_ohlcv, get_search, get_schema, and get_summary tools which target entirely different data.

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

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

The description makes the usage context clear: use this tool when the agent needs the user's own account, plan, or usage information. It does not explicitly mention alternatives or exclusions, but the sibling tool names are sufficiently distinct that confusion is unlikely.

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 discloses important behavioral traits beyond the readOnlyHint annotation: pagination via next_cursor, split-and-dividend adjustment for equities/ETFs vs unadjusted crypto, and credit cost details. These are valuable and not present in the annotations.

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

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

The description is three sentences, each with distinct value: purpose+use case, pagination, and behavioral caveats. It is front-loaded with the primary function, then adds necessary detail without wordiness.

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

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

With a rich output schema and comprehensive parameter descriptions, the main description covers all key non-obvious aspects: use case, pagination, adjustment policies, and credit cost. It is adequate for an agent to select and invoke the tool correctly.

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

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

The input schema has 100% description coverage, so the schema already documents all parameters in detail. The description adds contextual info like pagination and adjustments that relate to parameters but does not repeat or enhance individual parameter semantics beyond the schema.

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

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

The description begins with a specific verb ('Get') and resource ('stored end-of-day OHLCV candles') and clearly scopes to stock, ETF, or crypto ticker with daily or weekly timeframes. This distinguishes it from sibling tools like get_summary or get_search.

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

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

The description explicitly states when to use the tool: 'for exact-return calculations, charts, and backtests after get_summary identifies a setup.' It gives clear context and references the workflow with get_summary, though it does not explicitly name alternatives or conditions to avoid using it.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, establishing safety. The description adds behavioral context beyond these annotations by explaining that the tool returns field schemas and band values, and that it serves as a prerequisite validation step. It does not contradict annotations and discloses no side effects, which is appropriate.

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 only two sentences. The first sentence states the core purpose, and the second provides usage examples and tool relationships. Every clause adds value, with no redundancy or filler.

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

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

Given the tool has no parameters, an output schema exists, and annotations cover the safety profile, the description is highly complete. It explains what the tool does, when to use it, and how it fits into the broader workflow with other tools, leaving no critical gaps.

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

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

The tool has zero parameters, so the schema already fully documents the input (none). Per rubric, 0 params gets a baseline of 4. The description does not need to add parameter details, and none are missing.

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

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

The description begins with a clear verb+resource: 'Get the schema of all available fields and their valid band values.' This distinctly identifies the tool as a metadata/schema retrieval operation, differentiating it from sibling data-fetching tools like get_summary and get_search.

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

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

The description provides explicit usage guidance with concrete example queries ('what fields are available?', 'what bands does momentum_rsi_zone have?') and states it should be used to validate names before calling get_summary or get_search. This gives clear when-to-use context, though it does not list exclusions, it strongly implies the tool is for schema validation and discovery.

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

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

Annotations already declare safe read-only behavior. Description adds behavioral details beyond schema: field naming conventions (clean flat vs expanded names), default field subset behavior, tier-specific availability of insider/sector fields, and server-side sorting rationale. No contradictions; could further explain openWorldHint but not required.

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

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

The description is long but front-loaded with purpose and organized into consequential guidance (filters, fields, sorting, caveats). It earns its length; however, the density may slow scanning, so slightly below a perfect conciseness score.

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

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

For a complex search tool with seven params and an output schema, the description covers filter syntax, field discovery, default behavior, tier limits, and mode-specific constraints. It leaves no major functional gaps; output shape is handled by the schema.

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

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

Despite 100% schema coverage, description substantially enriches parameter understanding by explaining the raw vs semantic field name distinction, listing meaningful example filters, documenting default fields, and noting tier-gated availability. This goes far beyond the input schema's descriptions.

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

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

The description opens with 'Search for assets matching filter criteria' and enumerates specific categorical states and ranking use cases. This clearly identifies the tool as an asset-screening/search function, distinct from sibling tools like get_ohlcv or get_summary.

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 context: 'Use get_schema to discover valid field names', 'Pass filters as JSON-encoded array', and advises 'trend_stage is weekly-only and should be requested with timeframe=weekly'. However, it doesn't contrast with alternatives like get_summary or get_ohlcv for when not to use this tool, so not a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: paid tier restrictions, meta objects being off by default, stats mode returning aggregates instead of rows, and the ability to request explicit *_meta fields. This goes well beyond what annotations provide.

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 dense paragraph with a lot of details. It is front-loaded with the main purpose, but the sheer length and stream-of-consciousness listing of fields and modes make it harder to scan. While the complexity of the tool justifies some length, better structuring (bullets or sections) would improve conciseness.

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

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

Given the tool's complexity (17 parameters, 4 modes, paid tiers, nested objects), this description is exhaustive. It covers mode selection, field filtering, event semantics, stats behavior, meta flags, paid tier limitations, and even notes about fundamentals and insider_activity. The presence of an output schema means return values don't need explanation, and the description does not neglect any major aspect.

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 every parameter is already documented in the schema. The description adds some contextual semantics (e.g., 'Add stats=true in event mode' and 'meta=true or request explicit *_meta fields'), but these largely echo the schema descriptions. The description does help by grouping parameters into the four modes, but it does not significantly expand parameter 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 opens with a specific verb+resource: 'Get pre-computed market intelligence for a specific stock, crypto, or ETF ticker.' It clearly distinguishes this tool from siblings like get_ohlcv (raw price data) and get_search (search functionality) by focusing on pre-computed summary intelligence. The four modes are explicitly listed, making the tool's scope unambiguous.

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

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

The description provides clear context on when to use each mode (e.g., 'Snapshot (default) for the latest categorical state', 'Historical snapshot by date'), and explains conditional parameters like stats and meta. However, it does not explicitly state when NOT to use this tool or name alternative tools, so it stops short of a 5.

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

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

Despite annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds substantial behavioral context: it returns a full per-ticker summary that grows large, includes plan-dependent fields, explains empty-watchlist meaning, and discloses the notable_changes format. No contradiction with annotations.

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

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

The description is long but every sentence adds value: purpose, return field details, plan tiers, alternatives, and edge-case semantics. It is front-loaded with the core purpose and structured logically without redundancy.

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

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

Given the complexity of the output (many fields, plan-dependent data, notable_changes), the description is remarkably complete. It covers return value structure, plan variations, watchlist prerequisites, and when to prefer sibling tools, fully compensating for the absence of parameter docs.

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

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

The tool has zero parameters, so the baseline is 4. The description appropriately focuses on return semantics and use cases rather than param docs, which are unnecessary here.

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

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

The description opens with a specific verb+resource: 'Get analytical summaries for every ticker on the user's saved watchlist.' It clearly distinguishes itself from siblings by naming alternatives (get_summary for single ticker, get_watchlist_changes for deltas) and explicitly states the scope is the whole tracked set.

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?

Explicit usage guidance is provided: 'Use this only for questions that span the whole tracked set; for a question about one specific ticker use get_summary instead' and 'When the question is only whether anything changed, prefer get_watchlist_changes.' It also advises using add_to_watchlist first and clarifies the empty-watchlist semantics, covering exclusions and 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?

Annotations already mark it read-only and non-destructive; the description adds valuable context: data is based on the last pipeline run, stability metadata requires a Plus/Pro plan, and it returns only changed items. No contradiction with annotations exists.

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

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

The description is dense but every sentence earns its place: core function, supported comparisons, plan limitation, and sibling comparison. Front-loaded with the action, no fluff or redundancy.

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

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

The description is complete for a monitoring tool: it covers purpose, usage guidance, alternatives, plan restrictions, and temporal scope. An output schema exists, so lack of return-value detail is not a gap.

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

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

The only parameter, timeframe, is fully documented in the schema with enum values and default behavior. The description adds no additional parameter semantics beyond what the schema already provides; baseline 3 applies due to 100% schema coverage.

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

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

Description clearly states it gets field-level state changes for watchlist tickers since the last pipeline run, supporting daily and weekly comparisons. It also distinguishes itself from the sibling get_watchlist by noting it returns only deltas, making its scope precise.

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 recommends preferring this tool over get_watchlist for monitoring questions and provides a clear alternative: use get_watchlist when the full current state is needed. Also notes it is the only source for week-over-week changes, giving concrete when-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?

The annotations already include destructiveHint=true, but the description adds context that removal 'only stops tracking and can be undone with add_to_watchlist,' clarifying that it is not an irreversible deletion. This goes beyond the annotation by explaining the scope and reversibility, though it doesn't describe other potential side effects.

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

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

The description is two sentences long, front-loaded with the main purpose, and every sentence adds value: the first states the action, the second provides usage constraints and reversibility. No redundancy or irrelevant detail.

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

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

Given the tool's simplicity (one parameter), the presence of an output schema, and annotations covering destructive behavior and idempotency, the description provides sufficient context for a correct invocation. It covers the key decision points: when to call and what the effect is.

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 parameter 'tickers' is already fully documented with an example in the schema. The description does not add new semantic detail beyond what the schema provides, so the baseline of 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 the action: 'Remove tickers from the user's saved watchlist.' It uses a specific verb and resource, and the distinction from the sibling add_to_watchlist is implicit in the action itself. The tool's scope is well-defined.

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

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

The description explicitly instructs when to use the tool: 'Only call this when the user explicitly asks to stop tracking, remove, or drop a ticker.' It also gives a clear exclusion: 'never prune the watchlist on your own initiative,' and mentions undoing via add_to_watchlist, which guides agent decision-making.

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