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

With no annotations, the description carries the full behavioral burden. It discloses that execution is sequential and dry-run by default, but omits critical traits such as partial-failure behavior, atomicity, authorization requirements, and the irreversibility of live orders.

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 wasted text, and the key scope and dry-run default are front-loaded. 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?

This is a high-stakes batch trading tool with no annotations, no output schema, and incomplete schema coverage. The description should explain preview output, partial-failure semantics, and confirmation requirements, but it does not.

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 only 33%, so the description needs to compensate but largely does not. It adds the useful notion of market/auto-limit orders and one-account scope, but does not explain the orders array structure, quantity/action constraints, or account_number format.

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, resource, and scope: running several market/auto-limit orders sequentially in one account. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like fidelity_place_order or fidelity_stage_order.

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 'several ... orders one after another' implies this is for multi-order placement, and 'Dry run by default' gives operational guidance. However, it does not explicitly say when to use this instead of fidelity_place_order for single orders or fidelity_stage_order.

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. 'List' implies a read-only operation and the parenthetical discloses the return contents, but it does not mention whether a prior fidelity_login is required or what happens if the session is unauthenticated — relevant given a fidelity_login sibling 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?

Two clauses, zero waste, with the core purpose front-loaded and the redirect second. Every word earns its place.

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

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

For a no-parameter, no-output-schema read tool, the description covers purpose, return fields, and the key sibling alternative. The only missing piece is the authentication prerequisite implied by the fidelity_login/logout siblings.

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 takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The description's parenthetical about returned fields is a small bonus but not a substitute for parameter documentation.

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 Fidelity accounts') and even names the returned fields (number and nickname), which no structured field does. It explicitly separates itself from fidelity_get_positions, so an agent can select it without opening any 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?

Directly routes the alternative case: 'For balances use fidelity_get_positions.' That covers the main ambiguity between accounts and positions, though it says nothing about the other siblings (status, login, quote) or when an account listing is required as a prerequisite.

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

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

With no annotations, the description carries the full burden. It does disclose a useful behavioral trait — the data originates from a positions CSV, not a live API — and names the returned fields, but says nothing about login/auth requirements, behavior when no CSV exists, error modes, or whether the read is read-only/safe.

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 tightly-written sentence with the data source and returned fields front-loaded; every clause (source CSV, field list, `balance` alias) 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?

Since no output schema exists, the field enumeration is necessary and present. However, for a credential-gated financial tool the description omits auth prerequisites, failure behavior, and whether the CSV must already be exported, leaving real gaps for an agent to discover at call time.

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 takes zero parameters, so the baseline is 4; the description correctly frames it as a positional read requiring no inputs. Nothing in the description contradicts or obscures that.

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 ('Get') and resource ('holdings for every account'), and enumerates the returned fields (ticker, quantity, price, value, balance). It implicitly separates itself from fidelity_get_accounts by returning holdings rather than account metadata, though it never names that 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?

Usage is only implied: an agent can infer it's the tool for reading portfolio positions versus fidelity_get_quote for a single price. There is no explicit when-to-use, no mention of prerequisites such as fidelity_login, and no statement of when not to use 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully notes that extended-hours prices are included when available, but it does not disclose authentication requirements, data freshness/delay characteristics, or rate 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?

The definition is one front-loaded sentence with no filler. It states the core action and the key availability nuance 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?

For a simple one-parameter quote tool with a fully described input schema and no output schema, the description says enough about what is returned: last price and extended-hours price when available. It could still be stronger on authentication and quote freshness, but the missing pieces are limited.

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 is fully documented in the schema with an example ticker. The description adds only that the symbol may refer to a stock or ETF; otherwise it does not add 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 states a specific verb and resource: get the last price plus extended-hours price for a stock/ETF, sourced from the trade ticket. It is clearly about quotes, not accounts, positions, or orders, though it does not explicitly name sibling tools or alternatives.

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 guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. 'From the trade ticket' describes source context but does not tell an agent when this quote tool should be selected.

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

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

No annotations exist, and the description carries the full burden well: it discloses the visible UI, the up-to-10-minute wait, that the session is saved afterward, and the security guarantee that no credentials are requested or typed. This is exactly the behavioral context an agent needs before invoking a blocking, human-in-the-loop tool.

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

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

Three short sentences, front-loaded with what happens, followed by the wait/save behavior and the call-once constraint. Every sentence adds distinct information with no 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 zero-param, no-output-schema tool, the description covers trigger, duration, side effect, and safety. The only minor gap is what the caller should do if the 10-minute wait elapses without a completed login, but this is a small omission.

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 takes zero parameters, so per the rubric the baseline is 4. The description correctly implies there is nothing to supply, though it does not explicitly say 'no arguments required'.

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 (open a visible browser window on Fidelity's sign-in page) plus the scope that matters: the USER completes login and 2FA. It is clearly distinguishable from siblings like fidelity_status or fidelity_get_accounts, which never open a browser.

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?

Gives an explicit trigger ('Call once when a tool reports the session expired') and an explicit anti-pattern ('don't retry in a loop'). The agent knows both when to call it and when not to, without inferring from sibling names.

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 disclosure burden. It does add genuinely useful behavior — the saved session remains on disk — which prevents an agent assuming credentials are cleared, but says nothing about resource cleanup, whether re-login is needed, or whether the call is idempotent/safe.

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, action first and consequence second, with no filler. An agent can read it in one pass.

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 zero-parameter, no-output-schema tool this covers the essentials, but the name/behavior tension ('logout' vs. merely closing a browser with session preserved) leaves the agent unsure whether authentication state changes, which is the core question this tool raises.

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 takes zero parameters and the description adds nothing to invent, so there is no parameter semantics gap. Baseline 4 for a no-param tool.

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?

It says a concrete action — 'close the browser' — and clarifies the session persists, which is more informative than the name 'logout' alone, but that clarification also muddies what the tool actually does: it closes a browser rather than terminating a session. It distinguishes itself only implicitly from siblings such as fidelity_status or fidelity_login.

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 statement of when to call this versus keeping the session open, and no mention of prerequisites or an alternative tool. The 'for the next tool call' phrase hints that closing is safe between calls, but the agent has to infer the usage condition.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return contents well and implies a read operation, but does not mention that supplying url causes navigation (a side effect), nor any auth or permission requirements.

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

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

A single tight sentence that front-loads the returned content, then the optional navigation behavior, then the use case. No wasted words.

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

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

With one optional parameter and no output schema, the description usefully enumerates what comes back and when navigation occurs. Only the side effect of URL navigation and any access prerequisites are left 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 coverage is 0% for the single url parameter, so the description must compensate. It does explain that url is optional and triggers opening the page first, but gives no format, domain, or path detail — partial compensation only.

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 ('List') and the exact resources returned — buttons, links, form fields and tables — plus the fields (id, aria-label, text). It is clearly distinct from the financial-data siblings like fidelity_get_quote or fidelity_place_order, though it does not explicitly say so.

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?

'For fixing selectors' gives a concrete when-to-use context, and 'optionally after opening a Fidelity URL' explains the trigger for the url param. No exclusions or named alternatives are given, but the intended situation is clear.

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

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: preview-by-default, automatic coercion to limit orders for penny stocks and extended hours, and the one-tick-past-last-price fallback. It stops short of stating irreversibility, authentication requirements, or error behavior for a tool that moves real money.

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?

Four tight sentences, front-loaded with the action and the safe default. Every sentence carries operational information — no restatement of the name 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?

For a high-risk trading tool with no annotations and no output schema, the description covers the critical surfaces: safety default, order-type coercion, and what the response contains ('the exact order... for the user to confirm'). Quantity limits, account selection, and failure modes are left unaddressed, keeping it short of 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 only 43%, but the description adds genuine meaning for the trickiest interaction: when order_type becomes limit and how limit_price is derived if omitted. It leaves symbol, quantity, and account_number (the required 'Exact Fidelity account number') entirely to the schema, so compensation for the coverage gap is partial.

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 ('Buy or sell a stock/ETF') that an agent can map directly to an order-placement action. It does not, however, distinguish itself from the sibling fidelity_stage_order or fidelity_batch_orders, which sound like they serve overlapping purposes.

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 dry-run workflow is spelled out well ('Dry run by default... Only set false after the user confirmed' lives in the schema), giving clear context for the safe path. But there is no guidance on when to choose this tool over fidelity_stage_order or fidelity_batch_orders, which are the most likely routing ambiguities.

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 burden. It discloses that the tool may navigate to a URL before capturing, but omits authentication/session prerequisites, whether it affects the current page state, and what form the screenshot result takes.

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 filler, and the core action is front-loaded. The optional URL behavior and debugging purpose each add useful information without 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 simple one-parameter tool, the core action and optional URL behavior are covered. However, with no annotations and no output schema, the description should ideally clarify login/session requirements and the screenshot return format; those gaps leave it only minimally 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?

The single parameter is only a bare 'url' string in the schema with 0% description coverage. The description compensates by explaining that the URL is optional and, when supplied, is a Fidelity URL opened before the screenshot, which adds useful 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 states a specific verb and resource: screenshot the browser page. It also clarifies the optional URL behavior and frames the purpose as selector debugging. It does not explicitly differentiate from siblings such as fidelity_page_content, but the screenshot/debugging intent is clear.

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 'For debugging selectors' gives a clear use case, and 'optionally after opening a Fidelity URL' explains the main calling context. It does not name alternatives or when-not-to-use cases, but the intended usage is not left entirely 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?

With no annotations, the description carries the full burden and does so well: it discloses the visible browser window, that the tool stops at the preview screen and never submits, and that mutual fund orders fill at the next NAV rather than at an immediate price. It omits the returned payload (no output schema exists) and any authentication/prerequisite state (e.g., must already be logged in via fidelity_login) or failure 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?

Four sentences, front-loaded with the end-to-end behavior, then the share-vs-dollar rule, then the required user-facing message. No sentence is redundant, and the critical "never places" caveat sits immediately after the workflow it modifies.

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 7-parameter mutation-adjacent tool with no annotations and no output schema, the description covers what goes wrong most easily: accidental placement and wrong quantity units. Remaining gaps are the return value (e.g., whether a preview confirmation or order id comes back) and the precondition that the session must be authenticated, which the agent must infer from the sibling login tool.

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

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

Schema coverage is 57%, and the description compensates on the highest-risk ambiguity: quantity is whole shares for stocks/ETFs while amount is dollars for mutual funds, identified as 5-letter tickers ending in X with an example (FSKAX). It adds no guidance on order_type, limit_price, or account_number beyond what the schema already states, leaving those fields on the weaker schema descriptions.

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

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

The description states a specific verb and resource ("Set up a buy/sell for the USER to place") and then enumerates the exact sequence: opens a visible window, fills the trade ticket, clicks Preview, verifies it, leaves it on the preview screen. The sentence "this tool never places" draws a hard boundary against the sibling fidelity_place_order, so an agent can distinguish the two 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?

It clearly establishes the use context: a human-in-the-loop trade staging where the user performs the final Place/Cancel click, and it instructs the agent to tell the user the window is open. It does not explicitly name fidelity_place_order (or fidelity_batch_orders) as the alternative for automated placement, so the routing decision for multi-order or unattended flows is 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, the description carries the full behavioral burden. It usefully discloses that the tool does not navigate and identifies the statuses it reports, but it does not mention authentication requirements, whether it can start the browser, or any other 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?

Two short, front-loaded sentences with no wasted wording. The main purpose comes first, followed by the important non-navigation constraint.

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 zero-parameter status tool with no output schema, the description is largely complete: it names the three reported conditions. It could be slightly more complete by clarifying that it only observes and does not launch or authenticate the browser, but the key behavior is covered.

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 parameter semantics are inherently simple. The description adds no parameter detail, which is appropriate here, and the empty schema is sufficient.

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 reporting purpose with concrete status fields: browser running, sign-in page, and last session save time. It is clearly distinguishable from sibling actions such as fidelity_login, fidelity_logout, and fidelity_get_accounts, and explicitly notes that it does not navigate.

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 "Does not navigate" implies this is a safe status-checking tool, but the description does not explicitly say when to use it, when not to use it, or which sibling tools to use instead. Usage is inferable but not fully guided.

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 at all, the description carries the full burden and does disclose the critical trait: no dry run, submits immediately, irreversible-by-implication. It omits auth/login prerequisites, whether the transfer can be reversed or cancelled, and what a failure looks like.

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

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

Two sentences, no filler, and the irreversible/high-stakes warning is front-loaded immediately after the purpose. 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 3-param financial mutation with no annotations and no output schema, the description covers purpose, irreversibility, and the human-confirmation gate, which is the core risk surface. It leaves auth prerequisites and result semantics unaddressed, minor gaps given the tool's narrow shape.

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 only 33% (only 'amount' is documented, as 'Dollars'). The description names the three parameters, which confirms what the confirmation step must cover, but adds no format guidance for from_account/to_account identifiers, leaving those parameters undocumented in both places.

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 and resource ('Move cash') plus scope ('between two of the user's Fidelity accounts'), which is enough to distinguish it from order-placement siblings like fidelity_place_order. It stops short of explicitly naming the sibling it is not, so the differentiation is implied by 'cash' rather than spelled out.

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?

Gives a clear precondition: call only after the user has confirmed from, to and amount. That is real when-to-use guidance for a money-moving tool. It does not name an alternative (e.g., stage-then-execute via fidelity_stage_order) or state what to do if the user has not confirmed.

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