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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds genuinely useful behavioral context beyond the annotations: the 7-day expiry window and that a browser login (not an API token) is required, which shapes what the agent should tell the user.

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, zero waste, with the purpose front-loaded and the usage trigger as the closing actionable clause.

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 exists, so return values need not be described. For a zero-parameter, read-only auth check with full annotation coverage, the description provides everything needed: what it checks, why it matters, and when to call 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?

There are no parameters, so per the rubric the baseline is 4. Nothing in the description needs to explain inputs, and it correctly stays silent on them.

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 (Check) and resource (Schwab login validity/expiry), and adds the domain constraint that Schwab requires a new browser login every 7 days. No sibling tool overlaps with authentication status, so an agent can identify it immediately.

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

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

Explicitly tells the agent when to call it: 'Call this first if other tools report authentication errors.' That is a concrete routing condition tied to a failure mode of the sibling tools, which is exactly what usage guidance should do.

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 openWorldHint=false, so the agent knows this is a safe, closed-world read. The description adds one piece of genuine context — that US/Eastern is 'the exchange clock,' implying which timezone matters for trading decisions — but says nothing about precision, caching, or freshness.

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 compact clauses with the timezones front-loaded and the usage hint trailing. Every word earns its place and nothing is repeated from the schema or annotations.

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 parameters and an output schema that already documents the returned fields, the description only needs to frame what clock is returned and why; it does that. Minor gap: no indication of timezone format (e.g. ISO 8601) or freshness guarantees.

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?

There are zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly avoids padding with nonexistent arguments.

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 resource (current date and time) with concrete scope: US/Eastern and UTC. Clear enough that an agent instantly distinguishes it from siblings like get_market_hours, though it doesn't name those alternatives explicitly.

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 'Useful before date math' gives an implied usage context, but there is no when-to-use vs. when-not guidance and no named alternatives among the many sibling tools that also return time-related data (e.g. get_market_hours).

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds genuine behavioral context by disclosing the return semantics — session breakdown per day plus an active `session_now` field for today only — which the annotations do not convey.

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

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

Two tight sentences, zero filler, with the core capability front-loaded and the today-only `session_now` caveat following. Every clause 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?

An output schema exists, so the description is not obligated to explain return values, and what it does state (sessions, open flag, session_now) is sufficient for an agent to invoke the tool correctly. The remaining gap is the undocumented `markets` parameter, which is a minor completeness shortfall rather than a blocker.

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 only 50%: `date` documents its format ('YYYY-MM-DD, default today'), but `markets` has no description anywhere, including the description text. The description mentions neither parameter, so it does not compensate for the undocumented `markets` enum list (equity, option, bond, future, forex) or its default 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?

States a specific resource (trading sessions: pre-market, regular, post-market) and a specific clarification (whether the market is open), so an agent immediately knows what it returns. It does not explicitly name or contrast with siblings, but the purpose is distinct enough that differentiation is unnecessary.

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 only implied: an agent can infer this is for checking market open/closed state and session boundaries. There is no explicit when-to-use, when-not-to-use, or reference to alternatives such as get_current_time, which is the nearest sibling an agent might confuse it with.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds essentially nothing behavioral beyond that: it does not say how many movers are returned, whether results are paginated, or any rate/latency characteristics. The sorting detail it does provide is already available in the schema enum.

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 efficient sentence with the core scoping information front-loaded and no filler. It is appropriately sized for the tool, though it could have used one more clause for usage guidance without becoming bloated.

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 exists, so return formatting need not be described. Still, for a tool where every parameter is optional and behavior depends heavily on defaults (sort=PERCENT_CHANGE_UP, index=$SPX), the description omits the defaults and any guidance on selection, leaving the agent to read the schema to use it sensibly.

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 only 33% (only 'frequency' is documented in the schema), so the description must compensate. It partially does: 'sorted by volume, trades or % change' maps onto the sort enum values and 'index or exchange' hints at the index parameter. However, it does not explain that PERCENT_CHANGE_UP/DOWN are separate ranking directions, nor what INDEX_ALL/EQUITY_ALL/OPTION_* select.

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-less but clear operation: 'Top movers in an index or exchange, sorted by volume, trades or % change.' It identifies the resource (market movers) and the ranking dimension, which no sibling tool (get_quotes, get_price_history, search_instruments) provides. It stops short of explicitly distinguishing itself from siblings, but 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?

There is no indication of when to use this tool versus alternatives such as get_quotes or get_price_history, and no mention that all three parameters are optional or that defaults apply. Usage must be inferred entirely from the one-line purpose statement.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds the ordering trait "nearest expirations first," which is genuine behavioral context, but says nothing about pagination, rate limits, or default date-range behavior when from_date/to_date are omitted.

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

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

Two tightly packed sentences with zero filler; the return-value content comes first and the routing hint second, which is the right front-loading.

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 exists, so return values need not be detailed further, and annotations cover the safety profile. The main gap is that default date-range behavior when from_date/to_date are omitted is left unstated, but for a read-only market-data tool this is minor.

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 67%, with described params for symbol, from_date, to_date and strike_count. The description adds no parameter-level detail beyond implying date filtering, and the undocumented contract_type and max_contracts remain unexplained in both places. Baseline 3 is appropriate given the schema does most of the work.

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?

Names the resource (option chain) and enumerates its payload precisely: bid/ask/mark, volume, open interest, implied volatility and greeks. It also distinguishes itself from the date-selection sibling get_option_expirations, so an agent can tell the two apart without opening a schema.

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?

"Use get_option_expirations to pick dates" explicitly routes the agent to the right alternative for the expiration-window parameters. It gives clear context but offers no exclusion guidance about the other siblings (e.g. get_quotes vs this chain), so it stops short of a full 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 readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is fully covered without the description. The description adds only 'days to expiration' as return-content context, which is slight but useful given no other behavioral disclosures like ordering or pagination.

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?

One tight sentence with no filler, and the key scope (underlying, expiration dates) is front-loaded. It is efficient, though it stops before any statement that would help an agent choose it over alternatives.

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

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

For a one-parameter read tool with an output schema that carries return structure and annotations that carry the safety profile, the description tells the agent what it gets. The main gap is absence of routing guidance against get_option_chain in the adjacent toolset.

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

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

With a single parameter at 100% schema description coverage, the schema already documents 'symbol' as the underlying ticker. The description's use of 'underlying' reinforces meaning but adds no syntax or format detail beyond the schema, matching the baseline 3.

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

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

States a specific verb (lists) and resource (option expiration dates) scoped to an underlying, and adds the returned derivative (days to expiration). It is distinguishable from get_option_chain in scoping but never names the sibling, so it stops short of explicit differentiation.

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?

There is no when-to-use statement, no prerequisites, and no mention of the obvious alternative get_option_chain. The usage is only implied by the phrase 'for an underlying' and the tool name, so an agent gets little routing help.

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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the trailing 'Read-only.' largely repeats structured data. The description does add value by disclosing the return shape (legs, fills, average fill price), which the annotations do not cover, but says nothing about pagination or how max_results interacts with the filters.

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 short clauses, front-loaded with the resource and what it returns. Efficient and easy to scan, with only minor redundancy in the 'Read-only.' tail that duplicates the annotation.

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 exists, so return-value explanation is not required, and annotations carry the safety profile. The remaining gap is the absence of any when-to-use routing against sibling tools, but for a zero-required-parameter read tool this is largely complete.

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

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

Schema coverage is 75%, with days, status, and account well documented in the schema; only max_results lacks a description. The description's '(open, filled, cancelled...)' loosely gestures at the status filter but adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb ('Recent orders') and resource with descriptive content (legs, fills, average fill price), going beyond a bare name restatement. It is distinguishable from siblings like get_transactions and get_positions, though it never names or contrasts them explicitly.

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?

There is no guidance on when to use this versus get_transactions or get_positions, nor any mention of prerequisites such as retrieving an account first. Usage context (recent orders, lookback window) must be inferred from the parameter defaults.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context by noting results are merged/aggregated across all accounts, but says nothing about latency, cost, freshness of P/L, or data scope limits.

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

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

A single sentence, front-loaded with the scope phrase and then a compact enumeration of contents. No filler, no redundancy with annotations or 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?

An output schema exists, so return structure need not be explained, yet the description helpfully enumerates the key fields. For a zero-required-parameter read tool with full annotations and full param coverage, this is nearly complete; only explicit routing guidance against siblings 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?

Schema description coverage is 100% and top_n is fully documented in the schema with a default of 10 and bounds 1-50. The description's 'top holdings' hints at top_n but adds no meaning beyond the schema, so the baseline 3 is correct.

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?

Specific verb+resource ('get_portfolio_summary') with a full enumeration of the contents: total value, cash, today's P/L, unrealized P/L, allocation, top holdings, per-account totals. The phrase 'one-shot overview across all accounts' and 'merged across accounts' clearly distinguishes it from granular siblings like get_positions or list_accounts.

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 implied usage ('one-shot overview') tells the agent this is the aggregate call rather than a granular one, which is useful context. However, it never explicitly states when to prefer it over get_positions/list_accounts, nor any exclusions or prerequisites. Usage is inferable but not stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low. Beyond them, the description discloses the result ordering ('Sorted by market value') and that quote fetching yields 'live last/mark prices', which is genuine behavioral context. It still doesn't note the added latency or extra request cost of include_quotes=true.

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 dense sentences with no filler: the field inventory and sort behavior come first, and the optional live-quote toggle is placed last. Every clause carries information an agent can act on.

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?

This is a simple read-only tool with all parameters documented and an output schema that carries the return shape, so the description does not need to define return values in detail. The gaps, mainly routing guidance versus get_portfolio_summary, are modest.

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

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

Schema description coverage is 100%, so all three parameters (symbol, account, include_quotes) are already documented in the schema, establishing a baseline of 3. The description's note about include_quotes adding live last/mark prices partially duplicates the schema's 'adds a `live` block' text and adds little beyond 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 resource (holdings per account) and enumerates the returned fields (quantity, average cost, market value, unrealized and today's P/L, weight), which lets an agent tell it apart from generic siblings like get_portfolio_summary. However, it never names a sibling or explicitly contrasts itself with the portfolio/summary 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?

It gives one inline usage instruction ('Set include_quotes=true for live last/mark prices'), which is helpful but only covers one parameter choice. There is no guidance on when to prefer this over get_portfolio_summary, get_orders, or get_transactions, and no stated prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that results bundle candles with an aggregate summary, but says nothing about data source, latency, or rate limits; for an open-world market-data read, 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 front-loaded sentence that leads with the primary payload (OHLCV candles) and then the secondary summary fields. Every clause carries information; nothing is padded.

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 full output schema present, the description need not explain return values, and it correctly focuses on what data comes back. Combined with 100% schema coverage, an agent has nearly everything needed; only the choice against get_quotes is unstated.

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 fully documents all seven parameters, including the enum, defaults, and the period/start_date override relationship. The description adds no parameter detail beyond that, so the 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 names the concrete output (OHLCV candles plus change, % change, high/low, and average volume) and scopes it to a period, so an agent knows exactly what data it returns. It does not, however, explicitly differentiate itself from the sibling get_quotes tool, which is the nearest conceptual neighbor.

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?

There is no statement of when to use this tool versus alternatives such as get_quotes, nor any prerequisites or exclusions. 'For a period' hints at historical rather than real-time data, but the routing decision is left entirely 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?

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds the real-time nature of the data and what fields are returned, but does not mention rate limits, auth requirements, or data freshness guarantees beyond 'real-time'.

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 definition is a single front-loaded sentence with no filler. The field list is somewhat lengthy, but it remains readable and efficiently conveys the tool's scope.

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 read-only quote tool with full parameter documentation, rich annotations, and a separate output schema, the description provides enough context to invoke it. The main omission is guidance on choosing it over historical or option-chain siblings, which is a usage-guideline gap rather than a fundamental completeness 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%, so both the symbols format and include_fundamentals are fully documented by the schema. The description only alludes to optional fundamentals, adding little beyond the baseline for a high-coverage 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 states a specific resource (real-time quotes) and enumerates the returned fields, including options greeks and optional fundamentals. It distinguishes itself from historical tools through the 'Real-time' qualifier, though it does not name a sibling 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 explicit when-to-use or when-not-to-use guidance is provided. The agent must infer that this tool is for current quotes rather than historical data and that get_price_history is the alternative; the description offers no routing or prerequisite information.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description usefully adds the 'newest first' ordering, but says nothing about pagination, truncation, or the 100-default/1000-max result cap that affects 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?

A single front-loaded sentence with no filler; the resource and its contents are stated immediately and nothing is wasted.

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?

Because an output schema exists, return format need not be explained, and the description covers the resource scope plus ordering. It falls short only on the sibling boundary with get_orders and the result-cap/pagination behavior.

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 80%, so the schema already documents days, types, symbol and account; the description only loosely echoes the type categories. Since structured data does the heavy lifting, baseline 3 is appropriate, with max_results left undocumented.

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 resource (account transaction history) and enumerates the included categories (trades, dividends, interest, deposits/withdrawals, fees), so an agent knows what comes back. It does not, however, differentiate itself from close siblings like get_orders, leaving the agent to infer the boundary.

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?

There is no explicit when-to-use guidance or named alternative. The overlap with get_orders (which also returns trade activity) is left entirely to inference, so the agent has no stated rule for choosing this tool over that one.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered elsewhere. The description only adds a restatement of the returned fields, which the output schema also provides, so it contributes little behavioral context beyond the structured data.

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 short sentences with no filler; the purpose is front-loaded and the cross-tool hint follows immediately.

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 parameters, an output schema present, and annotations covering the safety profile, the description is nearly sufficient. Only minor gaps remain, such as whether multiple accounts can be returned or whether authentication must already be established.

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?

There are zero input parameters, so there is nothing for the description to disambiguate; baseline is 4. The description's mention of returned fields is output-side, not parameter-side.

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 ('List the linked Schwab accounts') and enumerates the returned fields (type, nickname, total value, cash, buying power). It is naturally distinguishable from siblings like get_positions or get_portfolio_summary, but it never explicitly contrasts itself with them.

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 second sentence gives clear workflow context: use the returned `account` labels with the other tools, positioning this as the discovery/entry step. It does not name an alternative or state a when-not condition, 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds a modest behavioral nuance: the fundamental mode returns a different shape of data than a plain lookup, which is a mode-dependent return trait rather than mere repetition. It says nothing about result limits, pagination, or whether the search is exact-match, so it does not go far 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?

A single front-loaded sentence with no filler; the primary capability comes first and the secondary fundamental mode follows. Slightly muddy because it compresses three distinct behaviors into one compound sentence that reads as one capability.

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 output schema exists, so return values need not be explained, and annotations cover safety. But the tool exposes five search types and the description addresses only three, leaving symbol_regex and description_regex behavior entirely to the schema, and one required plus one optional parameter with a default is thin coverage for a multi-mode search 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 description coverage is 100%, so both parameters are already documented in the schema, including the enum values and the example query. The description restates symbol/company-name/fundamentals use but adds no syntax, matching behavior, or regex-mode detail beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

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 concrete verb ('look up') plus the resource ('instruments') and enumerates the lookup modes: by symbol, by company name, or fundamentals for a symbol. It is distinguishable from siblings like get_quotes or get_price_history, which retrieve data rather than resolve identifiers. It stops short of naming a sibling, so it is clear but not maximally differentiated.

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 three clauses imply when each mode applies (symbol lookup, name lookup, fundamentals), which is useful implied guidance. However, there is no explicit when-to-use/when-not framing, no guidance on choosing among the five enum values, and no routing to alternatives such as get_quotes once a symbol is resolved.

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