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

No annotations are provided, so the description carries the full behavioral burden. It indicates a read-only, GET-like operation and accurately describes what the tool returns, but it does not disclose return format, date formatting, sorting, or error/rate behavior. This is adequate for a simple getter but minimal.

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 one clear, front-loaded sentence with no filler or redundant phrasing. Every word earns its place, and it avoids repeating the parameter schema.

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, simple read tool, the description is largely complete: it explains the return concept and the schema covers the invocation details. The lack of an output schema is mitigated by 'expiration dates' being a clear result, though no examples or follow-up workflow guidance are provided.

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%: the single symbol parameter already has a clear example-based description. The tool description adds no new parameter semantics beyond saying 'for a stock,' so the baseline score 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 states a specific verb and resource: 'Get all available option expiration dates for a stock.' This clearly identifies the tool's output and distinguishes it from sibling tools like get_option_chain or get_options_by_expiration_and_strike, which return different option 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 gives no guidance about when to use this tool versus alternatives. It does not mention that this is the precursor for option-chain or options-by-expiration calls, nor does it state any exclusions. Usage context is only implicit from the tool's name and output.

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 disclosure burden. It clearly states that this is a read-only list operation and describes the returned fields, which is helpful. But it does not mention pagination, time range, empty-result behavior, sorting, or any authentication-dependent behavior, leaving some behavioral ambiguity.

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 short sentences with no wasted words. The action and resource are front-loaded, and the second sentence efficiently enumerates the return format.

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 getter with no output schema, this description is reasonably complete: it states the scope ('all') and the return structure. Minor gaps remain, such as what 'instrument details' means precisely and how empty or paginated results behave, but these are not critical for basic 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 tool has zero parameters, so the baseline is 4. There are no parameter semantics for the description to add, and the 100% schema coverage means no undocumented parameters need compensation.

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 plus resource: 'Get all dividend payments received.' It also names the returned fields (amount, payable date, record date, instrument details), which clearly distinguishes it from siblings like earnings, news, or ratings. Even without naming a sibling, the purpose is 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?

Usage is implied by the tool name and 'dividend payments received,' so an agent can infer when to select it. However, there is no explicit guidance about when not to use it or which sibling alternative might be more appropriate for related data such as earnings or fundamentals.

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 are absent, so the description carries the full burden of explaining behavior. It only restates that this fetches earnings data; it does not disclose whether results are historical actuals, estimates, upcoming dates, or what fields will be returned. No output schema exists to fill this gap.

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 one short sentence with no filler and is front-loaded with the action. It is structurally concise, though the brevity contributes to the lack of 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?

With no output schema and no annotations, the description is not complete enough. 'Earnings data' is ambiguous and could mean earnings dates, EPS estimates, reported results, or a calendar. An agent can invoke the tool correctly with the symbol, but cannot anticipate what the response will contain or how to interpret it.

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

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

The single parameter 'symbol' is already fully described in the input schema, and schema description coverage is 100%. The description adds no meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses a clear verb ('Get') and resource ('earnings data') and names the target ('a stock'), so it is not a tautology. However, 'earnings data' is broad and does not distinguish it from siblings like robinhood_get_fundamentals or robinhood_get_ratings.

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 guidance is given about when to use this tool versus the many sibling tools. An agent must infer that 'earnings data' is distinct from fundamentals, news, ratings, or dividends without any explicit context 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the action without explaining side effects, data source, limitations, or what constitutes 'fundamental data.' It implies a read operation but does not confirm read-only behavior or any other 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?

The description is a single, tight sentence with no filler or redundancy. It is concise, though it sacrifices useful detail and reads almost like a restatement of the tool name, which keeps it from a higher 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?

The tool is simple with one parameter and an output schema, so the description does not need to describe return values. However, it lacks any behavioral context around what fundamentals are included or how this compares with similar data-retrieval siblings, leaving a clear gap for an agent deciding which tool to 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?

The schema already covers the single parameter 'symbol' with a clear description, and schema description coverage is 100%. The description adds no additional meaning beyond the schema, so the baseline score 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 states a clear action ('Get') and resource ('fundamental data for a stock'), so an agent understands the core purpose. It does not explicitly differentiate itself from sibling data tools like quote, historicals, earnings, or ratings, aside from the inherent meaning of 'fundamentals.'

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 guidance is given on when to choose this tool over sibling tools such as robinhood_get_quote or robinhood_get_historicals. There are no exclusions, prerequisites, or alternative routing instructions, leaving the agent to infer usage solely from the tool name and vague description.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states that historical price data is returned, with no mention of response format, rate limits, read-only guarantees, or constraints such as which intervals are valid for which spans.

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 with no filler and the core action front-loaded. However, it is arguably too generic, providing only the bare purpose statement and no additional 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?

With no output schema and no annotations, the description does not explain what the returned historical price data looks like, whether results are OHLCV candles, or which interval/span combinations are valid. It is enough for coarse selection but insufficient for fully informed 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 description coverage is 100%, and all parameters have descriptions, enums, and defaults. The description adds no parameter-level detail beyond implying symbol from 'stock,' so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: 'Get historical price data for a stock.' This meaningfully distinguishes it from siblings like get_quote or get_fundamentals, though it does not explicitly contrast with any sibling. It is not a tautology because it clarifies what 'historicals' refers to.

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 no guidance on when to use this tool versus alternatives such as get_quote, get_news, or get_fundamentals. It provides no context about typical use cases, no exclusions, and no mention of sibling tools.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It clarifies that the tool returns news articles, but it does not define what 'recent' means in terms of time window, limits, ordering, or output shape. For a simple read-only endpoint this is acceptable 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?

The description is a single, front-loaded sentence with zero wasted words. It states the action, the result type, and the subject of interest efficiently.

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

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

The tool is simple: one required parameter and no nested objects or output schema. Yet because there is no output schema and no annotations, the description leaves the return structure and recency semantics unspecified, making it adequate but incomplete.

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 'symbol' described as 'Stock ticker symbol.' The description repeats the symbol concept via 'for a stock' but adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'Get' and a clear resource, 'recent news articles for a stock.' It distinguishes itself from all sibling tools, which target quotes, fundamentals, options, portfolio data, and other non-news resources.

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 obvious use case: retrieve recent news when you have a stock symbol. However, it does not explicitly state when to use it versus alternatives and does not mention any exclusions or edge cases, though no sibling appears to fill a news role.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It only states the action and leaves out any return format, pagination, data fields (e.g., Greeks), or assurance that this is a read-only operation. The agent is left without information about what to expect from the response.

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

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

The description is a single, front-loaded sentence with no filler words. Every element adds meaning, and it is appropriately sized for the tool's simplicity.

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 no output schema and no annotations, so the description should compensate by explaining what data the 'full option chain' includes or any notable behavior. It briefly covers the core use case but omits details about the response structure or edge cases, leaving a moderate gap 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?

Schema description coverage is 100% with clear descriptions for all three parameters (symbol, expiration_date, option_type). The description adds no additional meaning over the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get the full option chain for a stock on a specific expiration date.' It distinguishes this from siblings by emphasizing 'full option chain' and the expiration-date scoping, which clearly separates it from robinhood_get_options_by_expiration_and_strike and robinhood_get_available_expirations.

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 when to use the tool (when you need the complete option chain for a given expiration), but it does not explicitly reference alternatives or state when not to use it. There are no exclusions or alternative routing, so guidance is only implicit.

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 behavioral disclosure burden. It only restates the operation at a high level and does not mention return format, default behavior for option_type, pagination, authentication requirements, or any other runtime behavior an agent would need to know.

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 with no filler. It front-loads the action and resource, then states the two key filters, making it efficiently scannable.

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 no annotations and no output schema, the description leaves important context unaddressed, such as what exactly is returned, whether option_type is needed for the desired result, and how this tool relates to the other options-oriented siblings. The minimal description is sufficient only for a very basic understanding of the tool's purpose.

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

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

Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds no new parameter semantics beyond restating that filtering is by expiration date and strike price, which keeps it at the baseline score.

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 action ('Get options'), the resource ('for a stock'), and the filtering dimensions (expiration date and strike price). It is specific enough to convey the core function, though it does not explicitly distinguish itself from the closely related robinhood_get_option_chain sibling.

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 choose this tool over alternatives such as robinhood_get_option_chain or robinhood_get_available_expirations. The intended use case is only weakly implied by the filters mentioned in the description.

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

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

With no annotations provided, the description carries the full behavioral burden and does disclose the key trait: the operation is read-only. It also states the return shape is a list and enumerates the fields, giving the agent a good sense of what to expect from the call.

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 concise sentences with no filler: one states the action and read-only nature, the second lists the returned attributes. Every sentence earns its place and is front-loaded for quick parsing.

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, read-only list operation, the description covers what the agent needs: the scope, safety profile, and returned fields. It does not mention alternatives or exclusions, but nothing about correctly invoking this simple tool is 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 tool has zero parameters, so there is no parameter documentation burden. The description reinforces this by saying 'all current options positions,' signaling no filtering inputs exist. Baseline 4 is appropriate because no additional parameter semantics are 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 opens with a specific verb and resource: 'Get all current options positions' with a clear read-only qualifier. The word 'options' distinguishes it from the sibling robinhood_get_positions and robinhood_get_position, so an agent can tell which tool handles options holdings.

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 the agent needs all current options positions, but it does not explicitly say when not to use it or name alternatives such as robinhood_get_positions for equity positions. The usage context is clear but left to inference.

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 must carry the full burden of behavioral disclosure. It states it returns equity, extended hours equity, and withdrawable amount, but does not explicitly confirm it is a read-only operation, nor does it mention any edge cases, authentication requirements, or limitations. The behavior is largely implicit from the 'Get' verb.

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: two sentences with no redundant wording. The first sentence states the primary purpose, and the second lists key return fields. It is well-structured and front-loaded, earning a top 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?

Given the tool has no parameters, a simple read operation, and an output schema that likely details the exact structure, the description provides a useful high-level summary. The phrase 'and other account details' is slightly vague, but the output schema fills that gap. There is no obvious missing information that would prevent an agent from calling it 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 tool has zero parameters, so the schema is already fully covered. The description adds value by outlining the return payload (equity, extended hours equity, withdrawable amount), which goes beyond the empty input schema. According to the baseline for zero parameters, this is a solid 4.

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

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

The description clearly states a specific verb ('Get') and resource ('current portfolio value and performance metrics'), which distinguishes it from sibling tools like robinhood_get_positions that focus on holdings. It also names the return fields, making the purpose explicit. However, it does not explicitly contrast with siblings, so it misses the top score.

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. It does not mention that this is for overall account value as opposed to robinhood_get_positions, nor does it state any prerequisites or use cases. An agent would have to infer from the name and 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 must carry behavioral disclosure. It adds useful context about currency ('current') and cardinality ('one'), which are not in the schema, but it doesn't cover what happens when no position exists, auth requirements, or rate-limit implications. This is adequate for a simple getter, 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?

A single front-loaded sentence states the action, object, scope, and performance benefit with no filler. It avoids repeating the title or restating schema contents.

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

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

For a one-parameter getter with an output schema, the essential invocation information is present: what it returns and that it is keyed by symbol. Missing explicit guidance on the all-positions sibling and edge cases like absent positions leaves a small gap, but nothing blocking.

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 input schema fully documents 'symbol' with a format example. The description only references the symbol indirectly as 'single-symbol lookup' and adds no format or behavioral detail beyond the schema. 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 opens with a specific verb ('Get') and resource ('one current stock position'), so an agent immediately knows what it returns. The 'faster single-symbol lookup' qualifier differentiates it from the sibling robinhood_get_positions, which naturally reads as the plural/all-positions counterpart.

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

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

The phrase 'single-symbol lookup' clearly indicates the tool is for fetching one position by symbol, so an agent knows when it is appropriate. It does not explicitly name the alternative for bulk/all-position lookups or state exclusions, 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?

There are no annotations, so the description carries the full disclosure burden. It does disclose the output shape (a dict mapping symbols to details including price, quantity, average buy price, equity, percent change) and implies a read-only operation via 'Get.' It does not mention authentication, rate limits, or error behavior, but the return-format transparency is valuable.

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 short sentences, front-loading the core action and then listing the returned fields. There is no redundant or filler content; 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?

For a zero-parameter tool with an output schema, the description is largely complete: it names the resource, scope, and return shape. It does not address potential ambiguity with sibling tools or explicitly confirm read-only behavior, but those are minor gaps given the simplistic interface.

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?

Input schema has zero parameters, so there is nothing the description needs to add about parameter meanings. The description correctly focuses on the output instead, and the schema coverage baseline applies. No param semantics are skipped.

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+resource: 'Get all current stock positions with details.' It distinguishes from sibling tools like robinhood_get_position (singular) and robinhood_get_options_positions by specifying 'all' and 'stock positions.' The return format is also briefly stated, so purpose is 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?

No explicit guidance is given about when to choose this over alternatives such as robinhood_get_position or robinhood_get_portfolio. The phrase 'Get all current stock positions' loosely implies usage when all positions are needed, but there are no when-not-to-use conditions or sibling comparisons.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get real-time quote' and gives no information about read-only safety, data latency, authentication requirements, rate limits, or possible error conditions. The lack of any safety or side-effect disclosure is a notable gap.

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

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

The description is a single, front-loaded sentence of nine words with no redundancy or filler. It efficiently captures the core purpose without unnecessary detail, making it easy for an agent to parse quickly.

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

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

Given the tool's low complexity, one well-documented parameter, and the presence of an output schema, the description is adequate for basic invocation. However, it lacks usage guidance and behavioral caveats (e.g., real-time data limitations, market hours), so an agent has incomplete context for choosing and relying on this 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 input schema fully documents the single parameter 'symbol' with an example, so the description adds no additional semantic value beyond what the schema already provides. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description states a specific action ('Get real-time quote') and resource ('stock symbol'), clearly indicating the tool retrieves current market data. It does not explicitly name sibling tools for differentiation, but the resource type is distinct enough from tools like get_fundamentals or get_historicals. The purpose is clear and specific.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention when a real-time quote is needed, nor does it reference any sibling tools or exclusions. An agent must infer the appropriate context from the tool name alone.

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 a read-only operation but doesn't disclose authentication requirements, rate limits, or any side effects. The description is essentially a restatement of the tool's function without additional behavioral context 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?

A single, front-loaded sentence with zero filler. Every word earns its place, and it's perfectly sized for a simple tool.

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?

An output schema is present, so return values are covered. However, the description lacks usage context (when to choose this over siblings) and any behavioral notes. For a simple one-parameter tool it's adequate, but it doesn't fully prepare an agent to select it 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% for the only parameter (symbol), so the baseline is 3. The description adds no extra meaning beyond 'for a stock,' which is already implicit in the parameter name and description. No additional context on formatting or usage is given.

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 and resource: 'Get analyst ratings summary for a stock.' This clearly distinguishes from siblings like get_quote and get_fundamentals by focusing on ratings. However, it doesn't elaborate on what the summary includes, so it's not as rich as an example that explicitly names an alternative.

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 guidance is provided on when to use this tool versus the many other Robinhood data tools. An agent must infer from the tool name that it's for ratings, but there's no explicit statement of use cases, prerequisites, or alternatives to avoid.

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 of behavioral disclosure. It only says 'Get stocks', implying a read operation, but does not mention what happens for unknown watchlists, whether results can be empty, or whether non-stock securities are included.

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, direct sentence with no wasted words. It is appropriately front-loaded and 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?

For a simple one-parameter read tool with complete schema coverage, the description plus schema supplies nearly everything an agent needs to invoke it correctly. Return-value expectations are not described, but no output schema exists to clarify them.

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

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

Schema description coverage is 100% and the single parameter already has a clear description and default value. The tool description adds no additional parameter meaning, which is acceptable since the schema fully documents it.

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

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

The description states a specific verb ('Get') and resource ('stocks in a watchlist'), making the core purpose clear. It does not explicitly distinguish itself from the many read-only sibling tools, but the watchlist concept is a natural differentiator.

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 guidance is given about when to use this tool versus alternatives like robinhood_get_portfolio or robinhood_get_positions. There are no exclusions, prerequisites, or context clues beyond the one-line description.

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 present, so the description carries the full burden of behavioral disclosure. It discloses the core operation (search by company name or ticker) and is not misleading, but it adds nothing beyond the schema-specified query format: no mention of partial-match behavior, result count, output shape, auth requirements, or limits. For a read-only lookup this is 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?

A single nine-word sentence that front-loads the verb and resource. Every word contributes meaning, with zero redundancy, filler, or buried context. This is an exemplary level of economy.

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

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

The tool is simple — one required, fully schema-documented parameter — so the bar is low. However, with no output schema and no annotations, the description leaves the agent guessing about the return shape (e.g., a list of matching symbols with names) and how those results should be consumed downstream. Adequate for the simplest invocation, with a clear gap around result 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 description coverage is 100%, so the 'query' parameter is already documented as 'Search query (company name or partial ticker)'. The description's 'by company name or ticker' largely restates the schema rather than adding new semantics such as case-insensitivity, fuzzy matching, or minimum query length. Baseline 3 is appropriate given full 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?

States a specific verb ('Search'), a specific resource ('stock symbols'), and the accepted query forms ('company name or ticker'). The verb 'search' clearly differentiates it from the sibling get_* tools, which all fetch specific data by an already-known symbol. This is a precise, unambiguous purpose statement.

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 alternative guidance is given. The intended workflow — searching for a symbol first, then passing it to a get_* sibling — is implied by the name and the shape of the sibling set, but never stated. There are no exclusions, conditions, or transition cues that would help an agent choose this tool over a sibling.

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