Manawa Terminal

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

Annotations only declare the generic non-read-only profile, and the description adds the substance annotations cannot express: the pending/filled/refused lifecycle, HIL card behavior, past vs future date handling, and dividend accounting effects on cash and open cost. It also documents that the terminal's 400 responses must be surfaced, not masked.

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?

Purpose is front-loaded and the material is dense rather than padded, but the short/cover paragraphs repeat the same sentence structure twice ('names the stock... qty is... price is...') and a few lines such as 'The card does not open again when the price hits' could be folded into the surrounding limit explanation. Length is largely justified by the tool's complexity.

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 13-parameter mutation tool with an output schema already covering return shape, the description covers everything an agent needs to call it correctly: valid values, conditional requirements, order lifecycle outcomes, and error handling. Nothing material 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 coverage is only 8% across 13 parameters with no enums, so the description must carry the load and it does: side values are enumerated, symbol documents the $CASH alias for deposits/withdrawals, qty/price semantics are given per side, expires_kind values and delete_after's expires_at dependency are stated, and on_touch documents a default of review. Remaining gaps (portfolio_id shape) are trivial.

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 opening sentence gives a specific verb (add) plus the resource (portfolio transaction) and enumerates every supported side, so the agent knows exactly what operation this performs. It is clearly separable from siblings like create_portfolio, edit_order, and cancel_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?

Explicitly states prerequisites (call get_portfolio_rules first for orders), the correct sibling to use for the case id (search_library item_id / list_library_items id), and behavioral exclusions such as 'pending means the card is open: do not ask again and do not send a second order.' It also tells the agent not to rewrite a refused error, which is real when-not guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is covered. The description adds a useful behavioral detail, 'No fill is written,' but does not explain irreversibility, permissions, or what happens to the cancelled order.

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 short, front-loaded, and free of waste. Purpose and key behavioral detail come first, followed by compact parameter documentation.

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

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

With an output schema present and annotations carrying the destructive profile, the description covers the core call context. It remains slightly incomplete on permissions and alternatives, but is sufficient for correct 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 0%, so the description must carry parameter meaning. It does document both parameters as UUIDs, which is useful, but only minimally and without format or sourcing details.

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

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

The description clearly states the specific action and resource: cancel an open portfolio order. It is distinguishable in intent from siblings like edit_order, but it does not explicitly name or contrast with 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?

The phrase 'open portfolio order' implies the tool should be used only for cancellable open orders, but there is no explicit guidance on when to use this versus edit_order or other order tools. The context is present but the usage boundary is only implied.

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=false and destructiveHint=false, but the description adds real behavior beyond them: 'Calling this stores the alert,' the lifecycle rule that max_fires controls when an alert 'leaves Active' (omitting it makes it repeat forever), and that empty agent_instruction means notify-only. It does not cover permissions or rate limits, so not a 5.

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

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

Front-loaded one-line purpose, then a dense Args block where every line earns its place because the schema has no descriptions of its own. No filler or repetition despite documenting 13 parameters.

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 13 mostly-optional parameters, 0% schema coverage, and an existing output schema (so return format need not be explained), the description supplies every per-type requirement, default, and enum an agent needs to construct a valid call. Nothing material 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 0% across 13 parameters, so the description carries the full burden and does so thoroughly: it supplies the alert_type enum values, the schedule_repeat enum (once/daily/weekdays/weekly/monthly) with default, direction values, example event_types ids, event_filters example with matching semantics, and the disambiguation 'notes ... Not the agent instruction.'

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?

Opens with a specific verb and the three concrete resource types it creates (price alert, event alert, clock), which cleanly separates it from list_alerts and delete_alert in the sibling set. An agent knows exactly what this tool produces without opening the 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?

Gives strong conditional guidance: which fields are required per alert_type (direction/threshold for price, event_types for event, schedule_at for schedule) and that a clock may omit the ticker. It never names an alternative tool or an explicit when-not-to-use 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?

With annotations already declaring readOnlyHint=false and destructiveHint=false, the description adds useful behavioral context by explaining that the folder can be nested under a parent or created as a root folder. This goes beyond the schema and clarifies the outcome of omitting parent_id, though it does not mention permissions or side effects.

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

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

The description is exceptionally concise: a one-sentence purpose statement followed by a compact args list. Every word earns its place, and the most critical information (root vs nested) is front-loaded. No fluff or redundancy.

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

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

For a simple create operation with only two parameters and an output schema present, the description is complete. It covers the purpose, parameter semantics, and the critical edge case of root vs nested folders. The tool's low complexity means no further context is needed.

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

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

Despite schema description coverage being 0%, the description compensates by explaining both parameters: 'name' as the folder name and 'parent_id' as a parent folder UUID, explicitly stating that omitting it creates a root folder. This adds significant meaning beyond the raw schema.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Create a library folder'. It also distinguishes from sibling tools by mentioning the 'library' scope and optional nesting, which differentiates it from create_library_item or create_portfolio.

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 context on how to use the parent_id parameter ('omit for a root folder'), which implies when to use it, but it does not explicitly discuss when to use this tool versus alternatives. There is no exclusionary guidance or 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?

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description is not responsible for basic safety disclosure. It adds useful behavioral detail like 'HTML is stored as source' and optional folder placement, giving the agent more context beyond annotations.

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

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

The description is efficient: a single opening sentence and a compact Args block that lists each parameter with meaningful detail. No filler or redundant statements.

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

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

The description covers all parameters, notes defaults and optionality, and there is an output schema (per context signals) so return values need not be explained. It could mention error conditions or uniqueness constraints, but these are not critical for a basic create operation.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter: title, content (with content_type interaction), folder_id (optional, root default), and content_type (default and format). This is rich, actionable semantic detail that the schema alone lacks.

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 verb ('create') and resource ('markdown or HTML document in the research library'), which distinguishes it from folder creation and other library operations. The mention of content types further clarifies the exact scope.

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 alternatives are mentioned. While the purpose is clear, the description does not guide the agent on when to choose this over create_library_folder or update_library_item, relying on inference from the name and sibling 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?

Annotations already indicate this is a mutation (readOnlyHint=false). The description only restates the schema parameters (name, currency) without adding any extra behavioral details such as idempotency, duplicate handling, or required permissions. It adds no information beyond what annotations and schema provide.

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

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

The description is extremely concise, leading with a clear purpose sentence and then listing the two parameters. Every sentence earns its place, with no filler or 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 two-parameter create tool with an output schema present, the description sufficiently covers the required inputs. It does not need to explain return values since the output schema exists. Minor omissions like duplicate name behavior are not essential 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 schema has zero description coverage for its parameters. The description compensates fully by explaining 'name' as the portfolio name and 'currency' as the base currency with a default of USD. This provides clear meaning beyond the raw schema definitions.

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 'Create a portfolio' with a specific verb and resource. This distinguishes it from sibling tools like create_watchlist or create_alert by targeting the portfolio entity.

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 context is clear: use this tool to create a new portfolio. It does not explicitly exclude any scenarios or mention alternatives, but the purpose is evident among the sibling tools. No exclusion is necessary for such a straightforward create operation.

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 only declare the generic write profile (readOnlyHint=false, destructiveHint=false), so the description carries extra weight and delivers: "weekly requires Pro" is a real entitlement constraint, and the notify-on-change seeding behavior explains the side effects after creation. It does not describe what the returned object contains, though an output schema exists to cover that.

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

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

Purpose is front-loaded in one sentence, followed by a short usage paragraph and a scannable Args block. A few phrases are product jargon ("Same rows as Terminal Save on /screener") but nothing is padding; the length is justified by five undocumented parameters.

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-required-parameter create tool with an output schema, it covers the essentials: entitlement gating, the baseline-seeding workflow, and notification semantics. Minor gaps remain around how the query blob's sub-keys are interpreted and whether re-creating a duplicate name is allowed.

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 0%, so the description must do all the work and it does: it documents every one of the five parameters, including allowed schedule values, the blank-name fallback, the notify_on_change default, and the query blob's key structure. This is exactly the compensation the low coverage requires.

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 first sentence names a concrete verb and resource ("Save a screener filter query") and adds the specific purpose (scheduled enter/exit notifies). It implicitly separates itself from run_screener by referencing it as a follow-up step, but it never explicitly contrasts with update_screener, so sibling differentiation is left partly to inference.

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 real operational guidance: seed the baseline either by passing last_symbols or by calling run_screener after create, and it notes the feature only fires when Settings Screener in & out is on. It stops short of stating when to create a new screener versus update an existing one, which is the obvious adjacent alternative.

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

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

The description only repeats the basic creation action and parameter names, adding no behavioral details such as idempotency, duplicate handling, permissions, or return value behavior. Annotations indicate readOnlyHint=false and destructiveHint=false, but the description offers no extra transparency beyond that minimal signal.

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, with a direct opening sentence and minimal parameter explanations. No fluff or repetition; every line serves a clear purpose and is front-loaded with the core action.

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

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

The tool is simple with two straightforward parameters and an output schema exists, so the description covers the essentials. However, it omits behavioral context like what happens on duplicate names or whether the action is reversible, and lacks usage guidance, leaving it adequate but incomplete for an AI agent.

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

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

The schema has no descriptions for parameters, so the description's Args section adds some value. 'symbols' is clarified with an example (['AAPL', 'MSFT']), aiding understanding, while 'name' is tautological ('Watchlist name'). This partially compensates for the 0% schema description coverage but is not deeply informative.

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

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

The description clearly states the tool creates a watchlist with a given name and ticker symbols, using a specific verb and resource. It distinguishes from siblings like update_watchlist by focusing on the creation action, though it does not explicitly contrast 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 description provides no guidance on when to use this tool versus alternatives such as update_watchlist or list_watchlists. It does not mention scenarios, prerequisites, or exclusions, leaving the agent without context for choosing this tool.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, and the description is consistent. It adds no extra behavioral context beyond 'delete by ID', but the safety profile is already covered.

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, front-loaded, and contains no unnecessary words. It earns every sentence.

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

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

For a simple delete operation with annotations and an output schema, the description covers the core action. However, it omits potential caveats like irreversibility or ownership requirements, though these are partially implied by the destructiveHint.

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 0% schema description coverage, the description partially compensates by specifying alert_id as a UUID. This adds meaning beyond the bare string type, though it lacks additional details.

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

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

The description clearly states the tool deletes an alert by ID, using a specific verb and resource. It distinguishes itself from sibling tools like create_alert and list_alerts.

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 use this tool versus alternatives, such as requiring an existing alert_id or confirming permanence. The description only states what it does without context for usage.

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

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

The description adds the key behavioral detail that the folder's contents are also deleted, which goes beyond the annotations' mere destructiveHint flag. It clarifies the cascading nature of the deletion, though it doesn't mention irreversibility (already implied by 'delete').

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 imperative sentence followed by a minimal args list. It is front-loaded and has no filler, earning a high score.

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

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

For a simple delete operation, the description covers the tool's purpose and parameter. The output schema handles return values, and annotations convey the destructive nature. However, it could mention error conditions or necessary permissions, but these are likely assumed for a straightforward delete.

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 only defines folder_id as a required string with no description. The description's Args block states 'The folder UUID', adding format information (UUID) that the schema lacks, which is helpful but minimal; it doesn't explain how to obtain the ID or any validation rules.

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 'Delete a library folder and everything inside it' with a clear verb and resource, and the 'everything inside it' distinguishes it from delete_library_item and other folder operations. This provides specific scope.

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 on when to use this tool over alternatives like move_library_folder or rename_library_folder is provided. The context only implies that deletion is intended for discarding a folder and its contents, but no exclusions or alternatives are mentioned.

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

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

The annotation already includes destructiveHint:true, so the destructive nature is known. The description adds valuable context that the deletion removes all stored versions, which is a behavioral nuance beyond the annotation. It doesn't mention irreversibility or permissions, but the annotation covers the core destructive trait.

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

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

The description is concise and front-loaded. The main statement is one sentence, followed by a minimal Args section. Every word contributes value with no redundancy.

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

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

For a single-parameter tool with an output schema and clear annotations, the description fully covers purpose, effect, and parameter semantics. The output schema handles return values, so no additional return info is needed. It is complete for its complexity level.

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 provides no description for item_id, so the description's Args section ('The item UUID') fills the gap. This is sufficient to understand the parameter format and purpose, though it is minimal.

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

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

The description clearly states the tool's function with a specific verb ('Delete'), a specific resource ('library document'), and important scope ('all of its stored versions'). This distinguishes it from sibling delete tools like delete_alert and delete_library_folder.

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 tool's purpose is evident from the name and description, so an agent can infer when to use it. However, it does not explicitly mention alternative tools or when not to use it. Since there is likely no alternative for deleting a library item, this is acceptable but not top-tier.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered by structured data and the bar is lower. The description adds only the qualifier 'saved' to convey persistence; it does not state whether deletion is irreversible, what happens if the ID does not exist, or whether ownership permissions are required.

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

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

Two short sentences, front-loaded with the action before the Args block; nothing is padded. The 'Args:' block is mild boilerplate but costs almost nothing in an otherwise lean description.

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

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

With an output schema present, return values need no explanation, and annotations cover the destructive read/write profile. For a single-parameter delete, the description is nearly sufficient; only edge-case behavior (missing ID, permission errors, irreversibility) 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 0%, so the description must carry the parameter burden, and it does: screener_id is identified as a UUID sourced from list_screeners. That adds real meaning (identifier type and provenance) beyond the bare 'Screener Id' title in the schema, though it omits format/validation details.

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: 'Delete a saved screener by ID.' This clearly separates it from delete_alert, delete_library_item and delete_library_folder by resource type. It stops short of explicitly routing the agent against siblings (e.g. pointing to list_screeners as the discovery step), so it is clear but not fully differentiating.

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: 'The screener UUID from list_screeners' hints the agent should call list_screeners first, but there is no explicit when-to-use, when-not-to-use, or note that this permanently removes a saved screener. The workflow hint is useful but the guidance 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the meaning of the sector filter ('SIC sector stored on the chunks'), the ticker-vs-sector tradeoff, and comparison semantics. It says nothing about result ordering, pagination, or how the print/price-move data is surfaced, but the output schema is present to carry that.

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

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

Front-loaded purpose followed by routing guidance and a structured Args block. The Args list is long, but with 13 parameters at 0% schema coverage each line earns its place; the only slight redundancy is restating the sector examples in both prose and the Args list.

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?

A 13-parameter read-only search tool with an output schema and no schema descriptions is fully specified: context (calls, print, price move), selection modes, all parameter semantics and constraints, and cross-references to siblings are all present. Nothing an agent needs to invoke it correctly 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 0%, so the description carries the full burden and does so well: every one of the 13 params is given meaning, format (YYYY-MM-DD), bounds (last_n_quarters 1-8, chunks_per_ticker 1-5 default 3, fiscal_quarter 1-4), and pairing rules (fiscal_year with fiscal_quarter, compare_from with compare_to, last_n_quarters 'Not used with compare'). This is exactly the compensation a zero-coverage schema requires.

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: 'Retrieve what was said on earnings calls, plus the print and the price move.' It also names the sibling it is not (finance_search for reporting dates, the Earnings Deep Dive, and full-transcript requests), so an agent can distinguish it without opening the sibling schemas.

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 explicit when-to-use scenarios ('one season across several names, or this season versus a prior season'), the selection rule between input modes ('Pass tickers you already have, or a sector label such as Financials or Technology'), an explicit exclusion ('Do not invent symbols'), and where to go for adjacent needs (finance_search).

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 non-read-only, non-destructive, closed-world; the description adds real value beyond that by disclosing that an empty library_item_id removes the case, that HIL may reopen the accept card, and that a day order requires an open session. The HIL sentence is garbled ("HIL on, or an order above Skip HIL up to"), so the most consequential behavioral note is not fully actionable.

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

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

Front-loads the core action well, but library_item_id is explained twice (body and Args) and the HIL/session paragraph reads as fragmented prose rather than structured rules. The garbled HIL clause and repeated parameter listing cost space without adding clarity.

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 2-required/8-optional mutation tool with an output schema, the description covers the parameter surface, session prerequisites, and HIL re-confirmation. It leaves ambiguous what happens on partial failures or how the reopened accept card affects the call's return, which matters for a mutation.

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 13%, but the description compensates thoroughly: it explains expires_kind values (day, gtc 90 days, delete_after), that expires_at is required with delete_after and naive times are New York, and that after_hours is for stocks/ETFs. The library_item_id doc-id-vs-title trap and the empty-string removal semantics are spelled out explicitly.

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 ("Change an open portfolio order") and explicitly positions it relative to cancel_order and search_library/list_library_items. An agent can tell it apart from the cancel sibling without opening either 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?

Gives a concrete sequencing rule ("Use this before cancel_order") and the key operating constraint ("Send only the fields that change"). It implies rather than spells out the full decision rule (e.g., when to edit vs. cancel and re-place), so it falls just short of exhaustive.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return format as an answer with an inline widget and explains exclusive modes, but it does not disclose auth requirements, rate limits, error behavior, or other operational traits beyond the annotations.

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

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

The description is front-loaded with purpose and usage, and most of the many routing rules are relevant for a complex search tool. However, it is dense and extremely long, with some sections feeling like a knowledge base rather than concise tool guidance.

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

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

Given the tool's complexity and the lack of an output schema, the description is largely complete for selection and invocation, especially around modes, sections, and screening workflows. It is thinner on return values beyond the inline widget, but the invocation-critical semantics are well 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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does thoroughly. It explains query, symbols, section, focus, and source, enumerates section values and raw tapes, and disambiguates subtle routing cases like buzz vs. sentiment, acceleration vs. movers, and options vs. realized vol.

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 (search financial data) and domain coverage, and explains that it returns an answer with an inline widget. It distinguishes itself from list_watchlists and list_portfolios for screening, but does not clearly differentiate from run_deepdive or earnings_rag despite mentioning Deep Dive modes.

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 explicit usage instructions, routing rules, and alternatives such as calling list_watchlists or list_portfolios before screening. It also states when to use specific sections and when not to route certain questions to news, catalysts, movers, or the sector treemap.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds behavioral context: draft IDs are not readable until end-of-day, and valid IDs come from list_journal, which clarifies timing constraints 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?

Brief, front-loaded purpose, followed by essential usage and parameter details. No wasted words; Args block cleanly documents the single parameter.

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 operation with output schema present, the description covers purpose, eligibility of IDs, and parameter format. Complete and self-sufficient.

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 only defines entry_id as a string with no description. The description's Args section explains entry_id is a journal entry id from list_journal, accepts integer or UUID, providing critical meaning at 0% schema coverage.

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

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

Description clearly states 'Get a full generated journal entry by ID from list_journal', specifying verb, resource, and scope. It distinguishes from sibling tools like list_journal and submit_journal_draft.

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 explains when to use: after end-of-day generation, using list_journal for valid entry IDs, and warns against using draft IDs from submit_journal_draft. This provides clear context and alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. The description adds valuable context beyond annotations by specifying that content can be markdown, raw HTML, or a signed PDF URL depending on content_type. However, it does not disclose error behavior for invalid IDs or how versioning interacts with the returned content.

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 compact and front-loaded: purpose first, content-type behavior second, and a minimal args line. Every sentence earns its place, and the UUID clarification in the args block justifies its small redundancy with the 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 simple one-parameter, read-only tool with an output schema and safety annotations, the description covers the key complexity: the conditional content representations. The main gaps are where to source item_id and behavior for nonexistent items, which are minor given the tool's simplicity and the presence of an output schema.

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

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

Schema coverage is 0%, so the description must compensate. It does add meaning by stating item_id is 'The item UUID,' which is more specific than the bare string type in the schema. However, this is minimal compensation — it does not clarify where the UUID comes from (e.g., list_library_items) or expected format, leaving the agent to guess.

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-resource pair ('Get a library document's metadata and content') and elaborates on what is returned. It is distinguishable from siblings like list_library_items (plural listing) and get_journal_entry (different resource type), though it never names a sibling explicitly, which keeps it just shy of a 5.

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 choose this tool over alternatives such as list_library_items, list_library_item_versions, or search_library. No when-to-use, when-not-to-use, or prerequisite conditions are stated, so the agent must infer selection purely from the tool 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?

Annotations already declare readOnly=true, destructive=false, and closed-world, so safety is covered. The description adds real behavioral context beyond that: default unread filtering, page-size default of 50 with a max of 100, an upstream cap of 50 for unread, and newest-first ordering for history results.

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 scope rule is front-loaded in the first sentence, followed by a compact per-parameter list. It is appropriately sized with no filler, though the trailing cap note is vague enough to read as noise rather than a precise 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 three-parameter read tool with a published output schema and annotations covering the safety profile, the description supplies everything an agent needs to invoke it correctly: scope defaults, pagination behavior, and ordering. Only the sibling routing question (vs. list_alerts) is left unaddressed.

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 0%, so the description carries the full burden and largely succeeds: it documents all three parameters with defaults, the page-size maximum, and the semantics of history ('return fired alerts including ones already read, newest first'). The 'Unread upstream cap is 50' note is terse and slightly ambiguous, but no parameter is 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 gives a specific verb and resource ('Get alert notifications') and states the default scope (unread only) versus the broadened scope (history). It does not, however, distinguish itself from the sibling 'list_alerts', which an agent could plausibly confuse with this notification-fetching tool.

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 rule 'Unread only, unless history is set' gives the agent a clear condition for changing scope, but there is no explicit when-to-use guidance and no named alternative among the siblings (e.g., list_alerts for alert definitions). Usage is implied rather than 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value on top by disclosing what the returned rules contain (permitted assets, maximum order size) and by stating it is not a mutation path. It doesn't cover failure behavior for an unknown portfolio_id, which keeps it from a 5.

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

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

Front-loaded with the verb+resource, then usage, then the behavioral constraint, then the single argument. Four short lines with no padding; even the Args block earns its place by adding the UUID 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?

The tool is a simple single-parameter read, an output schema exists so return structure needn't be described, and the description still summarizes what the rules express and what the tool cannot do. Nothing an agent needs to invoke it correctly 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 0%, so the description carries the burden, and it does specify that portfolio_id is a UUID rather than an arbitrary string or name. With only one required parameter, this is nearly sufficient, though it omits where to obtain the UUID.

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 ('Read the order limits for a portfolio') and immediately clarifies the boundary against siblings: it is a prerequisite check, not a mutation. An agent can distinguish it from add_transaction and edit_order 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?

Explicitly says when to call it ('Call this before add_transaction on a buy, sell, short, or cover'), naming both the alternative tool and the exact triggering conditions. It also rules out misuse with 'This tool cannot change the rules.'

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 (readOnly, non-destructive, closed-world), so the description need not restate that. It adds useful semantic rules — gross/net exposure in book currency, negative weights and dividend_income, and the double-count warning — but these describe how to interpret returned figures rather than the tool's operational behavior (auth needs, scoping, 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?

The purpose is front-loaded and the sentences are short, but a large share of the text explains return fields (exposure, dividend_income, total_gain) that the output schema already covers, so not every sentence carries unique weight.

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 detail is somewhat redundant, while the description omits practical context such as when to prefer this tool over sibling listing tools. Adequate for a simple one-parameter read, but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter, and it does only minimally by specifying 'The portfolio UUID', adding a format hint (UUID) beyond the schema's bare 'Portfolio Id' string. With one parameter this is acceptable but thin.

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 portfolio performance statistics' — and parenthetically names the content scope (returns, allocation, risk). This clearly separates it from CRUD siblings like list_portfolios and get_positions, though it does not explicitly name 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?

There is no when-to-use or when-not-to-use guidance and no named alternatives. The '(returns, allocation, risk)' hint implies content but gives no condition for choosing this over get_positions or list_portfolios.

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, destructiveHint=false, and openWorldHint=false, but the description adds substantial domain behavior beyond that: how short positions are represented with negative shares and cost basis, how cash is affected by short proceeds and dividends, and where realized P&L lives. This is exactly the kind of non-obvious accounting context an agent cannot infer from annotations or schema.

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 front-loaded with purpose, then domain-specific behavior, then an Args section. The short-position paragraph is dense but earns its place by clarifying non-obvious return semantics; it could be tightened slightly, but there is no 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?

An output schema exists, so return fields do not need full re-explanation here, yet the description still adds essential accounting semantics for shorts, cash, and dividends. Together with read-only annotations and a single required parameter, an agent has everything needed to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter. It only states 'portfolio_id: The portfolio UUID,' adding format information but not explaining where to obtain the UUID or any constraints. With one required parameter and no deeper semantics, a baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Get current holdings') and lists the exact data returned (quantity, cost basis, market value, unrealized P&L). It also distinguishes the tool from get_portfolio_statistics by noting that realized P&L belongs there, so an agent can tell the two apart without opening either 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 implies use for current position values and explicitly routes realized P&L questions to get_portfolio_statistics, which is a helpful alternative. It lacks explicit when-not-to-use guidance or a direct comparison to list_portfolios, so it falls 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the read can target either a current or a historical generation and names the payload shape, which is useful but thin given an output schema already exists to document the return value.

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

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

Front-loaded one-line purpose followed by a compact Args block; every sentence maps to either routing or a parameter and there is no 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 2-parameter read tool with annotations and an output schema, the description covers what the tool returns, both parameters, and how to source them. The only gap is the format/validation of the `generation` value and a stray unbalanced markdown marker, both 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 0%, so the description carries the full burden and does so: strategy_id is identified as a Strategy UUID sourced from list_strategies, and generation as an optional GCS generation for an older save sourced from list_strategy_versions. It doesn't spell out the accepted format of a GCS generation string, which keeps it off a 5.

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 + scope: 'Read one strategy's current or historical generation', with the returned content named (markdown, settings, links). It also implicitly separates itself from the list_* siblings by naming list_strategies and list_strategy_versions as the sources of IDs rather than as alternatives for reading content.

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 clearly states the condition that selects the `generation` path ('for an older save') and points to list_strategy_versions as the way to obtain it, which is real routing guidance. It doesn't explicitly state when not to use this tool (e.g., versus list_strategies for bulk listing), so it stops short of full when/when-not coverage.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful scoping fact that only the authenticated user's alerts are returned, plus the enum-like categorization into price/event/clock alerts, but says nothing about ordering, pagination cursor behavior, or what happens when offset exceeds the total.

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

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

Front-loaded purpose sentence followed by a compact Args block; no filler. The Args section partly restates schema defaults, but that redundancy is the intended compensation for 0% schema description coverage.

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 shape need not be described. The alert categories, user scoping, and pagination parameters are all covered; the remaining gap is the absence of any note about ordering or total-count limits for paging through large alert sets.

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 0%, so the description must carry the parameter burden and largely does: offset is explained as 'Skip this many alerts (default 0)' and limit as 'Page size (default 50, max 100)'. The max of 100 is a real constraint absent from the schema, though the two parameters' interaction (offset must be a multiple of limit, etc.) is unstated.

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 resource (alerts) and narrows scope to 'price, event, and clock alerts for the authenticated user', which is more specific than the title. It does not name a sibling explicitly, but the list-vs-create/delete distinction against create_alert and delete_alert is obvious from the verbs.

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 when-to-use context and no comparison to plausible alternatives such as get_notifications. The only usage signal is the implicit scoping of 'for the authenticated user', which is context, not guidance.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds meaningful behavioral context beyond annotations: the generation-run lifecycle gating data visibility, draft exclusion, and the upstream retention limit of at most 90 days.

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

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

Front-loads the purpose, then the behavioral constraints, then the parameter list in a scannable Args block. Every sentence contributes, with only slight redundancy between the ordering note and the lifecycle note.

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 unnecessary, and the description is complete enough to call correctly: it covers paging params, ordering, visibility lifecycle, draft exclusion, and retention limits.

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%, so the description must carry the parameter documentation, and it does: offset (skip N, default 0) and limit (page size, default 50, max 100). It also adds a non-obvious upstream constraint (at most 90 days) that the schema does not encode. Minor gap: no guidance on page-size tradeoffs, but semantics are otherwise complete.

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 resource (generated daily research journal entries) plus ordering (most recent first). It also distinguishes itself from siblings by noting that drafts from submit_journal_draft are not listed, so an agent can tell it apart from submit_journal_draft and get_journal_entry without opening other schemas.

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?

Clearly explains the context in which entries become visible (only after the automatic end-of-day generation run) and warns that drafts are excluded until then. It does not, however, explicitly route the agent to an alternative (e.g., get_journal_entry for a single entry), so it is strong on context but lacks explicit when-not/alternative guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds that results are scoped to the authenticated user's library, which is useful behavioral context, but it says nothing about ordering, total counts, or what happens past the final page.

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?

Purpose is front-loaded in a single sentence, followed by a compact Args block with no filler. The docstring-style 'Args:' formatting is slightly mechanical but costs little.

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 shape need not be described. For a simple two-parameter paginated list with read-only annotations, the description covers scope and both parameters adequately, though it omits any note on ordering or how to detect the last page.

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 0%, so the description must carry parameter meaning, and it does: offset is explained as 'skip this many folders' and limit as page size with a max of 100, a constraint absent from the schema. It is not exhaustive about interplay between the two, but it meaningfully compensates for the undocumented 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 ('List folders') and scopes it to the authenticated user's research library, which is enough to distinguish it from mutation siblings like create_library_folder or delete_library_folder. It does not explicitly call out its relationship to list_library_items or search_library, but the noun (folders) is clear enough on its own.

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 tool versus alternatives (e.g., search_library, list_library_items) and no stated preconditions or exclusions. The reader must infer usage purely from the name and one-line purpose.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds pagination behavior (offset/limit defaults, max 100), which is useful context beyond annotations, but says nothing about ordering, total counts, or response shape.

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

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

Front-loaded one-sentence purpose followed by a compact Args block. Every line is functional; the only minor issue is the slightly redundant restatement of defaults already in the 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 read-only list tool with an output schema, the description covers purpose, scope, and all parameters including an undocumented max limit. Nothing critical is missing, though ordering/pagination semantics could go further.

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 0%, so the description must carry the load — and it does: it names all three parameters with meaning, defaults, and the max limit of 100, which is not in the schema. This adds real value over the bare 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?

States a specific verb (List) and resource (documents in a library folder), and clarifies scope (root if no folder given). This distinguishes it from search_library and list_library_item_versions by being a browse/list operation over a folder hierarchy.

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

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

Implies usage through the folder_id semantics (omit for root), giving context for the no-filter case. But it doesn't explicitly contrast with siblings like search_library or list_library_item_versions, so an agent must infer when to pick this over search.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds 'newest first' ordering, which is a useful behavioral trait beyond the annotations. It does not mention pagination or limits, but for a simple read-only operation this is acceptable.

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 highly concise, consisting of one sentence stating the purpose and an Args list. Every word earns its place, and the key information is front-loaded.

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

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

For a single-parameter, read-only tool with an output schema available, the description covers the essential purpose, ordering, and parameter format. It does not describe return values, but the output schema handles that responsibility.

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 description defines item_id as 'The item UUID', which adds format meaning beyond the schema's generic string type. With only one parameter, this sufficiently compensates for the 0% schema description 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?

The description clearly states the tool lists version history for a library document, with a specific ordering (newest first). This distinguishes it from sibling tools like list_library_items (which lists all items) and get_library_item (which retrieves a single item).

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

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

The description implies usage (retrieve version history for a specific library item) but does not explicitly state when to choose it over alternatives or exclude cases where it is not appropriate. There is no mention of when not to use it, such as needing current content rather than history.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds pagination context (defaults and max) but says nothing about ordering, total counts, or result shape. With annotations carrying the safety profile, this is an adequate but not rich disclosure.

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?

Purpose is front-loaded in a single clear sentence, and the args block is compact. The 'Args:' layout slightly duplicates the schema, but 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?

An output schema exists, so return values need not be explained. Pagination is documented, safety is covered by annotations, and the tool is simple (2 optional params). Sufficient for correct 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 0%, so the description carries the burden and does so well: it documents both offset ('skip this many') and limit ('page size, default 50, max 100'), including the max=100 cap that appears nowhere in the schema. This meaningfully exceeds the bare property names.

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 resource ('portfolios') and scopes it to 'the authenticated user's,' which distinguishes it from siblings like create_portfolio or get_portfolio_statistics. Clear but does not explicitly name an alternative for disambiguation.

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 when-to-use, when-not-to-use, or alternative routing is provided. It never distinguishes itself from get_portfolio_statistics or get_positions, leaving the agent to infer usage from the verb 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description only adds the modest clarification that screeners consist of filter queries plus a schedule, and says nothing about ordering of results or pagination behavior beyond the parameters.

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

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

Front-loaded with the purpose in the first sentence, then a compact args list. The args block partially restates schema defaults, but the max:100 detail earns its place, and there is no 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?

An output schema exists, so return values need not be explained, and the tool is a simple two-parameter lister. Adding result ordering or whether pagination is offset-based cursor would complete it, but nothing critical for correct invocation 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 0%, so the description carries the burden and does so: it explains offset as 'skip this many screeners' and limit as 'page size' with default 50 and max 100 — the max is information the schema does not contain. It stops short of stating ordering or total-count 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 verb and resource ('List the authenticated user's saved screeners') and clarifies what a screener is with the parenthetical '(filter queries + schedule)'. This distinguishes it from run_screener/create_screener well enough, though it does not explicitly name 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?

The description gives no when-to-use guidance or routing to siblings such as run_screener (execute one) or create_screener (make one). The agent must infer from the name that this only enumerates saved screeners.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: it names the exact fields returned, states what is deliberately omitted (full markdown), and discloses the write-path constraint requiring the Terminal browser or agent.

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

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

Three short lines, each earning its place: what it lists, what it omits, and the sibling to use instead. The core purpose is front-loaded in the first sentence.

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

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

With an output schema present, return values need not be explained, yet the description still summarizes them. For a zero-parameter read tool with full annotation coverage, nothing an agent needs to call it correctly 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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The field list it provides is return-value information rather than parameter guidance, but it does not mislead.

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 scope ("List the authenticated user's agent-rail strategies") and enumerates the fields returned. It immediately distinguishes itself from get_strategy, which returns the full playbook text.

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 routes the agent: this tool is the lightweight listing, and get_strategy is the alternative when full markdown, settings, and links are needed. It also notes that strategy writes require the Terminal browser or agent, telling the caller this tool cannot be used for mutation.

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 establish read-only and non-destructive behavior. The description adds ordering ('newest first') and content ('with version notes'), which are useful beyond the annotations, though it does not discuss pagination or empty results.

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 front-loaded and compact: one sentence states what is listed and its ordering/content, followed by a narrowly scoped Args note. 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 single-parameter, read-only list tool with an output schema and clear annotations, the description is nearly complete. The only minor gap is no explicit note about pagination or empty result behavior, though the output schema likely covers return 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 0%, so the description carries the burden for the single parameter. It identifies the value as a Strategy UUID and points to list_strategies as the source, adding meaningful semantics beyond the bare 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: list saved generations for a strategy. It adds useful scope details (newest first, version notes), so an agent can distinguish this from get_strategy or list_strategies.

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 implies usage by saying versions are for a strategy and that strategy_id comes from list_strategies, but it does not explicitly compare against get_strategy or state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results are scoped to the authenticated user and implies paging via offset/limit, but says nothing about ordering, empty results, or rate limits beyond that.

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

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

The purpose is front-loaded in the first sentence and the parameter notes are compact with no filler. The Args block is slightly docstring-ish but every line 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 two-parameter read tool with an output schema already describing return values, the description covers scope, pagination, and defaults adequately. Only ordering/empty-result behavior is unaddressed, which is minor here.

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%, so the description carries the load: it documents both parameters, their meaning ('Skip this many lists', 'Page size'), and their defaults, and adds the max of 100 that the schema does not contain. This is meaningful added value over the bare integer properties.

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 ... watchlists and their symbols') and scopes it to the authenticated user, which distinguishes it from sibling listers like list_portfolios or list_alerts by resource. It does not explicitly name alternatives, but the resource 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?

The description gives no when-to-use context, no prerequisites, and never mentions the sibling tools (create_watchlist, update_watchlist) or when this list is preferable to another. Usage is only inferable from the name and purpose.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds valuable behavior beyond that: admin-only restriction, empty options meaning skip the item, inclusion of already-rendered images for cache reuse, and status limited to live/draft in catalog mode. No contradiction with annotations.

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

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

The description is compact and front-loaded, opening with the admin-only and mode distinction before moving to per-parameter guidance. Every sentence adds useful information, and the Args section is 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?

Given the tool's moderate complexity, five optional parameters, and existing output schema, the description covers the key operational context: access control, item vs. catalog modes, parameter semantics, cache reuse, and skip behavior. Nothing essential is missing for correct selection and 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 0%, so the description carries the full burden, and it documents all five parameters meaningfully. It explains content_id's expected gc:{id} or rd:{uuid} formats, labels section/language/format as catalog filters, restricts status to live or draft, and adds the 'empty options means skip' behavior.

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

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

The description states the tool serves live formats for one inbox item or the catalog, clearly identifying its resource and scope. It distinguishes two modes (item vs. catalog), which helps differentiate its purpose, though it does not name a specific sibling alternative or use an explicit verb like 'get' or 'list'.

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 actionable usage context: admin-only access, passing content_id from marketing_inbox for a specific item, and using catalog filters without content_id. It conveys when to use each mode but does not explicitly contrast with sibling tools like marketing_render or marketing_inbox, so no exclusions or alternatives are named.

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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses that the tool is admin-only, returns already-generated images, and connects to a worker poll concept. It also signals a follow-up workflow with marketing_graphics, which is valuable behavioral context not present in annotations.

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

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

The description is tightly packed: purpose, access restriction, filter usage, sibling-tool transition, and reusable output hints all fit into a few lines. The Args block is clearly formatted and the most important operational guidance is front-loaded.

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

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

With an output schema present and safety annotations in place, the description covers all operational essentials: admin access, filter semantics, limit bounds, and the relationship to marketing_graphics. No critical calling information is missing; the only minor gap is the lack of an explicit allowlist of content_type values, which is likely dynamic and out of scope for a static description.

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 0%, but the description fully compensates by explaining each parameter: since is an ISO timestamptz, ticker filters current items for a symbol, type is an allowlisted content_type or research_drop, and limit is constrained to 1–200 with a default of 50. This adds meaning far beyond the bare schema properties.

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 identifies the tool as returning the latest teasers and already-generated images, and explicitly contrasts it with marketing_graphics for live formats. It lacks a direct imperative verb like 'List' or 'Get', but the scope and resource are unmistakable.

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

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

Provides explicit routing guidance: use ticker for symbol-scoped items, type for cross-symbol content_type filtering, and since for the worker poll. It also tells the agent when to call marketing_graphics and when to reuse items[].images[], leaving no ambiguity about selection.

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

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

The description goes well beyond the annotations by disclosing blocking behavior ('Blocks until GCS has the PNG'), cache behavior ('or a cache hit'), the 'Do not poll' directive, the draft-format error condition, and the admin-only restriction. It also explains the force parameter's cache-bypass effect, giving the agent a clear model of the tool's runtime 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?

The description is compact and front-loaded, with the most important facts ('Admin only', 'Render one live format', blocking behavior) in the first sentence. The Args section is clearly formatted and each line adds distinct value with no redundancy or filler.

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

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

Given the tool's moderate complexity, the description covers prerequisites (admin, live option), input format, blocking semantics, error behavior for drafts, and cache-related options. Since an output schema is present, return-value details are not required, and nothing essential for correct invocation 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 0%, so the description carries the full burden for parameter meaning. It fully compensates by explaining content_id format ('gc:{id} or rd:{uuid}'), option_id origin ('live option from marketing_graphics'), and force semantics ('Bypass render cache'), covering all three parameters with actionable detail.

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: 'Render one live format and wait until image.url exists.' It clearly identifies the resource (live marketing format), the operation (render), and the async behavior, and it references the sibling tool 'marketing_graphics' as the source of valid option_ids, which helps distinguish this from related 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?

The description gives clear operational guidance: admin-only access, render live formats only, wait for the image URL rather than polling, and expect option_not_live for draft formats. It lacks an explicit 'when not to use this tool' or named alternative tools, but the draft-format exclusion and pointer to marketing_graphics provide strong contextual routing.

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 that this is not read-only and not destructive, so the bar is lower. The description adds that moving to root is possible by omitting parent_id. However, it doesn't mention potential side effects like whether child items move along or if the operation is reversible.

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 short, front-loaded with the main purpose, and uses a clear Args block. No unnecessary words or 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 move operation, the description covers the operation and parameters. It doesn't explain return values, but an output schema exists so that is not needed. It could mention whether the move is recursive or if there are prerequisites, but the essentials are present.

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

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

Schema has no parameter descriptions (0% coverage), but the description's Args section fully explains both parameters: folder_id is the UUID to move, and parent_id is the new parent or null for root. This adds significant meaning beyond the schema.

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

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

The description clearly states the action (move), the resource (library folder), and the scope (under a different parent or root). It distinguishes itself from siblings like 'move_library_item' (moving items) and 'rename_library_folder' (renaming).

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

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

The description makes it clear this is for moving library folders, and the sibling names provide context (e.g., move_library_item for items). It doesn't explicitly exclude alternatives, but the scope is unambiguous.

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

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

Annotations already indicate the operation is not read-only and not destructive. The description adds the root-destination nuance but does not disclose other potential side effects (e.g., whether the item is removed from its previous folder), which are fairly obvious for a move operation. Given annotation coverage, the description provides adequate but not exceptional transparency.

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

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

The description is a single clear sentence plus a compact Args block that adds value (null behavior). No wasted words or redundancy beyond the 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 simple two-parameter move operation with an output schema and annotations, the description provides all necessary context. It covers purpose, parameters, and destination semantics completely.

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 0%, but the description's Args section fully explains both parameters, including the item_id as UUID and folder_id as destination with null-for-root behavior. This fully compensates for the missing 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 uses a specific verb ('Move') and resource ('library document'), and clarifies destination options ('different folder' or 'root'). It clearly distinguishes from sibling tools like move_library_folder and delete_library_item.

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 clearly implies when to use this tool—when moving an item between folders. It does not explicitly exclude alternatives, but the context is sufficient and unambiguous.

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

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

The description adds no behavioral context beyond the annotations. Annotations already declare readOnlyHint=false and destructiveHint=false, and the description simply repeats the rename action without mentioning side effects, permissions, reversibility, or effect on folder contents. It provides no additional transparency beyond what annotations 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?

The description is extremely concise, with the purpose stated first in a single sentence, followed by a minimal Args section that adds necessary parameter details. Every sentence earns its place, and there is no redundancy or fluff.

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

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

Given the tool's simplicity (two required parameters, an output schema present, and a clear rename operation), the description covers the essential invocation details. It does not mention potential error conditions (e.g., folder not found, duplicate name), but these are not critical for a straightforward rename and are partly handled by the presence of an output schema.

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

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

With schema description coverage at 0%, the description compensates by defining both parameters: 'folder_id: The folder UUID' and 'name: New folder name'. This adds meaningful semantics beyond the bare schema (which only lists types and titles), clarifying that folder_id is the unique identifier and name is the replacement name.

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

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

The description 'Rename a library folder' clearly specifies the action (rename) and the resource (library folder), distinguishing it from sibling tools like move_library_folder, create_library_folder, and delete_library_folder. It is a specific verb+resource statement, not a tautology.

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 provided. The usage is implied by the tool's name and purpose—it is for renaming an existing library folder—but it does not state when it should be preferred over move or delete, nor any prerequisites like folder existence.

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

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

The description reveals key behaviors: it is a write operation (logging a bug), has a daily rate limit, and data goes to the same inbox as the terminal bug button. This adds context beyond the minimal annotations (readOnlyHint=false, destructiveHint=false) and discloses no contradictions.

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

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

The description is concise and front-loaded with key purpose and usage. However, the parameter list uses a markdown 'Args:' block that is somewhat readable but could be more structured (e.g., bullet points) for easier parsing. Still, no unnecessary sentences.

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 0% schema coverage and no enums, the description covers everything needed: parameter semantics, use case, rate limit, and admins' needs. The output schema exists, so return values need not be explained in the description. The tool is simple and the description is fully adequate.

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

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

Schema description coverage is 0%, so the description fully compensates. Each parameter is explained with context: description's character range (10–2000), ticker as stock symbol, section as tab names, and page_url as optional terminal link. This adds substantial meaning beyond the schema titles.

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 'Log a bug' with a specific verb and resource. It also mentions the rate limit (5 per user per day) and distinguishes itself from sibling tools, none of which relate to bug reporting.

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

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

Explicit guidance is provided: use only when the user asks or when a real data/UI error is confirmed, and do not file speculative bugs. It also advises passing ticker/section for admin convenience, giving clear when-to-use and what-to-avoid instructions.

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?

Adds substantial behavioral detail beyond annotations: the call is async (returns when queued, do not poll), it consumes a monthly grant, and prepaid credits are rejected. Annotations (readOnlyHint=false, destructiveHint=false) are consistent with a side-effecting but non-destructive queueing tool — no contradiction.

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?

Well front-loaded: purpose, then billing/quotas, then async behavior, then args. All sentences earn their place, especially the concrete force example. Slightly long at ~100 words, but the quota breakdown and re-run nuance justify the length for a tool with billing implications.

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

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

Covers everything needed to invoke correctly: quotas, billing exclusions, async return behavior, force semantics, and parameter enrichment. The output schema covers return values. Minor gap: no mention of where completed results are delivered, though the 'do not poll' note mitigates the uncertainty.

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 0% schema description coverage, the description fully compensates: ticker gets format and example ('AAPL'), and force gets precise semantics ('Re-queue every chapter even when a current report exists') plus a concrete when-to-use example (ZS thesis written as soybeans). This far exceeds the bare schema titles.

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?

Opens with a specific verb-resource-scope: 'Queue a full DeepDive suite for a stock using a monthly custom-run grant.' This adds queueing behavior and the grant mechanism beyond the title, and no sibling tool queues analysis runs, so it is clearly 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?

Gives explicit when-to/not-to-use context: prepaid search credits are excluded, plan quotas are spelled out (Free 0, Basic 10, Pro 50), and re-running an already-unlocked ticker consumes no grant. It does not name an alternative sibling, but no sibling closely overlaps this action.

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 only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false; the description adds substantial context beyond that, disclosing a state mutation (persist last_symbols) and conditional notification side effects ('first seed does not notify', later runs notify joiners/leavers when Settings Screener in & out is on). It doesn't specify where last_symbols is persisted or whether the run is idempotent, keeping it short of a 5.

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 key action and its side effects are front-loaded in the first sentence, with notification nuance and the arg doc following. 'Same path as Terminal Run now' is somewhat cryptic internal jargon, a minor drag, but overall the text is tight and earns its space.

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 spelled out, and the description still hints at them (entered/exited). It covers mutation, notifications, and parameter sourcing, leaving only minor gaps such as failure modes or whether repeated runs dedupe notifications.

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 0%, so the description must carry the load, and it does: it identifies screener_id as a UUID and names list_screeners as the source. That is meaningful sourcing/format guidance beyond the bare 'string' type in the schema, though it adds nothing about error behavior for invalid IDs.

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 ('Re-run') on a specific resource ('a saved screener') and further distinguishes its behavior from siblings by declaring it persists last_symbols and returns entered/exited. This cleanly separates it from create_screener, update_screener, list_screeners and delete_screener.

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 implies prerequisites by telling the agent the screener_id comes from list_screeners, so the workflow is inferable. However it never explicitly states when to prefer this over create_screener/update_screener or what conditions make a re-run appropriate, leaving usage 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds helpful context about scoping to the authenticated user's library and the max result cap of 50, but it does not detail ranking, pagination, or result shape beyond what the output schema provides.

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

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

The description is concise, with a clear front-loaded purpose sentence followed by a compact Args block. Every sentence adds information, and there is no redundancy with the schema beyond necessary clarification.

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

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

With an output schema present, the description does not need to explain return values. It adequately covers the tool's purpose, user scope, and parameter behavior, and annotations cover safety. A minor gap is lack of mention of result sorting or that it searches document content vs metadata, but overall it is complete for a simple 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 0%, so the description must compensate. It defines query as 'Search terms' and limit as 'Max results (default 20, capped at 50),' adding the cap information that is not present in the schema. This is sufficient for both parameters, though 'Search terms' is somewhat generic.

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 action: 'Full-text search across the authenticated user's library documents.' It identifies the resource (library documents) and scope (authenticated user's), and distinguishes itself from sibling finance_search by specifying 'library documents' rather than financial 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 implies usage for full-text searching within the user's library, but it does not explicitly state when to use this tool over alternatives like list_library_items or finance_search, nor does it mention exclusions. The context is clear but lacks direct guidance.

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

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

Annotations only indicate non-readonly and non-destructive. The description adds critical behavioral detail: the draft is accepted immediately, the readable entry is generated at end of day, and the draft id cannot be used with list_journal/get_journal_entry until then. This is beyond what annotations 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?

The description is compact and front-loaded with the primary action, followed by essential caveats. The Args section is clearly structured. Every sentence adds value without redundancy.

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

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

For a tool with two-phase behavior and an id mismatch, the description covers all key points: same-day resubmissions, immediate acceptance, automatic generation, appearance in list_journal, and the temporary id discrepancy. It is complete despite the lack of parameter details in the schema.

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

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

Schema coverage is 0%, but the description provides an Args section explaining entry_date as 'Day the draft is for (YYYY-MM-DD)' and content as 'Draft text.' This compensates for the schema's bare property names and gives format guidance.

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 'Submit a journal draft for a day,' a specific verb+resource+scope statement. It further distinguishes itself from siblings like list_journal and get_journal_entry by clarifying that the returned draft id is not the same as the entry id until the end of day.

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

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

The description provides clear context for use: same-day resubmissions are retained as separate drafts, and the entry appears in list_journal only after end-of-day processing. It doesn't explicitly name alternatives or when-not-to-use, but the context is sufficient for an agent to select this tool for draft submission.

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 provide readOnlyHint=false (mutation) and destructiveHint=false (not destructive). The description adds key behavior: content edits create a new version, document type does NOT change, and content format handling (markdown vs HTML). This goes beyond annotations and is critical for agent expectation. No contradiction, though it could mention if title edits also create versions (unclear), but that's a minor 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 concise: two sentences then an Args list. It front-loads the purpose and version behavior. The Args list is clean and matches schema parameters. Every sentence adds value—the format guidance for content is essential. No fluff or 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?

The tool has an output schema (not detailed in the prompt, but present), so return values need not be explained. With 3 params, the description covers the behavior of each. It doesn't mention error cases (e.g., invalid item_id) but that's not typically required. The versioning behavior is explained well. Missing: whether title-only updates create versions, but that's minor. Overall, sufficient for an agent to call 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 description coverage is 0%, so description must compensate. The description explains that 'title' and 'content' are optional and lists their semantics (title vs content). It clarifies that content is markdown or HTML. However, it doesn't explain 'item_id' beyond being a UUID, but the schema name 'Item Id' and required status are self-explanatory. Baseline for low coverage is 1, but description adds meaningful detail, hence 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?

The description states a specific verb ('Update') and resource ('library document'), and clarifies scope: title and/or content, with content edits creating a new version. It differentiates from siblings like 'create_library_item' and 'delete_library_item' by implying this is for existing items, and from 'list_library_item_versions' by noting version creation. The 'versioned' in title is reinforced by the description.

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 clearly indicates when to use it: to modify an existing library item's title/content, and implies not for creating or deleting (siblings exist). It mentions content handling for markdown vs HTML, which is a context-specific instruction. However, it doesn't explicitly state when NOT to use it or name alternative siblings for creation/deletion, but the context signals include those siblings and the purpose 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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description's remaining job is constraint disclosure, and it delivers: every argument is marked optional, implying patch semantics rather than replacement, and 'weekly requires Pro' surfaces a gating condition that appears nowhere in the schema. It stops short of describing failure behavior for an unknown screener_id or what happens to fields left unset.

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 lead sentence front-loads the scope of the update, and the Args block is one line per parameter with no filler. It is efficient, though the field list is duplicated between the opening sentence and the Args block, which costs a little redundancy.

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

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

With an output schema present, return values need no explanation, and all six mutation parameters are documented with optionality and value constraints. The residual gap is behavioral: no statement of what unspecified fields do (unchanged vs cleared) and no permissions guidance beyond the Pro note on weekly scheduling.

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 0%, so the description carries full parameter burden and does so complete: screener_id is sourced from list_screeners, query is defined as a 'filter blob', schedule is given its three legal values, notify_on_change is explained as the enter/exit toggle, and last_symbols is defined as refreshing the baseline from the live table. All six parameters gain meaning unavailable in the raw schema, which exposes only titles and types.

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 (Update) and resource (a saved screener) and enumerates the mutable surface: name, query, schedule, baseline symbols. An agent can distinguish it from create_screener/delete_screener/list_screeners by name alone, though no sibling is named explicitly, which keeps it short of a 5.

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 rather than stated: it edits an existing screener, so create_screener is not the tool, and the screener_id note points the agent at list_screeners for discovery. There is no explicit when/when-not framing and no mention of run_screener as the execution counterpart, leaving the agent to infer the update-vs-run boundary.

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

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

The description states it updates a watchlist but does not disclose whether the symbol list is replaced entirely or merged, or what happens if name or symbols are null. Annotations indicate it's a write (readOnlyHint=false) but not destructive (destructiveHint=false), yet the description adds no further behavioral context.

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

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

The description is concise with a one-sentence summary followed by an Args list. It is front-loaded and free of fluff, but the Args block partially duplicates schema information and could be streamlined.

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 an update tool, the description should clarify that symbols replaces the entire list and note any permissions or existence requirements. The output schema may cover return values, but key behavioral details are missing, making the description incomplete for a mutation operation.

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

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

The description adds brief semantic labels: 'The watchlist UUID' for watchlist_id, 'New name (optional)' for name, and 'Updated list of symbols (optional)' for symbols. This goes beyond the raw schema but lacks detail on symbol format, replacement behavior, or validation rules.

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

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

The description clearly states the tool updates a watchlist's name and/or symbols, identifying the specific action and resource. This distinguishes it from sibling tools like create_watchlist and list_watchlists, though it does not explicitly name 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?

There is no guidance on when to use this tool versus alternatives, such as creating a new watchlist or deleting one. The description does not mention any prerequisites or conditions for updating, leaving the decision context unspecified.

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