Coil Scanner

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds a meaningful behavioral rule ('one licence per person, quantity 1') and reveals that this is a mutation (adding to cart). However, it does not mention idempotency, whether adding an existing item increments quantity or errors, cart persistence, authentication, 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 very concise: two short sentences with no wasted words. The storefront context and example are front-loaded, and the key constraint is stated clearly. It earns its place with actionable information.

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 mutation tool, the description is minimally adequate: it names the action, gives an example product ID, and constrains quantity. But with no annotations and no output schema, it could usefully state what happens after adding (e.g., whether the item goes straight to a specific cart, whether success or error is returned, or whether duplicates are merged). That would make it fully complete for an agent.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does: it gives an example of a product_id value and states that quantity should be 1. However, it does not explicitly explain what product_id represents beyond the example, nor does it describe how quantity behaves if omitted or supplied.

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: adding a billing variant to a storefront cart, with a concrete example ('coil-scanner-monthly'). It distinguishes itself from the sibling tools like remove_from_cart and update_cart_item by the explicit 'add' action, though it does not name or directly contrast those alternatives.

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

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

The description provides a storefront context and a quantity constraint ('One licence per person, quantity 1'), but it does not explain when to choose this tool over remove_from_cart, update_cart_item, or checkout_handoff. No explicit when-to-use or when-not-to-use guidance is given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that nothing is charged and that promo codes apply while a sale is live, but it does not explain return shape, idempotency, or whether it creates external checkout sessions.

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

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

Two compact sentences front-load the key idea and add only essential safety and context details. There is 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 no-parameter tool with no output schema, the description provides adequate context: what it produces, where the customer pays, and the no-charge guarantee. It could be more explicit about the exact return format, but the core information is 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?

The tool has zero parameters, so parameter semantics are trivially satisfied; schema description coverage is 100% and no compensation is needed. The baseline for a zero-parameter tool 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 identifies the resource—hosted checkout URLs for each cart line—and the intended handoff action, distinguishing it from siblings like get_cart or update_cart_item by pointing to external payment completion. It lacks an explicit verb like 'returns' or 'generates,' but the function is still reasonably clear.

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

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

The description gives clear context: use this when the person needs to complete payment at the hosted storefront. It does not explicitly name alternatives or exclusion conditions, but the payment-step context is unambiguous enough.

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

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

With no annotations, the description carries the full burden. It discloses critical behavioral traits: data is sha256-committed before outcomes were known, append-only, never revised, and costs $0.02 USDC per call. This provides transparency about data integrity, mutation policy, and pricing beyond the basic tool name.

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, using three sentences to convey purpose, integrity guarantees, usage variation, and pricing. It front-loads the core value proposition ('Point-in-time archive') and avoids redundancy; 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?

Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It covers the purpose, the historical/provenance use case, the append-only behavior, the cost, and the variation when omitting the date. It does not explain the return format, but that's not necessary given the tool's straightforward nature.

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

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

The schema already provides 100% coverage of the single 'date' parameter, describing it as an archived date in YYYY-MM-DD format and noting it can be omitted for the archive index. The tool description repeats this usage ('omit date for the list of archived dates') without adding new semantics, so a baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as a point-in-time archive of Coil's published scores for a specific archived date, distinguishing it from live/free counterparts by emphasizing sha256-committed, append-only data and backtest-grade provenance. This specific verb+resource+scope definition differentiates it from sibling tools like get_full_board.

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: it is for backtest-grade historical data, explicitly noting 'no free counterpart' and instructing to 'omit date for the list of archived dates.' It implies use for archival/provenance needs rather than live data, though it doesn't name explicit alternative 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?

With no annotations provided, the description fully covers behavioral aspects: it discloses the billing model ($0.01 USDC per call, free on unchanged hash), the read-only nature (implied by polling), and the precise output scope. It also notes there is no free twin, preventing confusion about costs.

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 information-dense but not padded; every sentence serves a purpose (purpose, usage, billing). It is slightly verbose but justified by the tool's complexity. The key loop-primitive usage is front-loaded, and the billing note is clearly separated.

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 absence of an output schema, the description adequately details the return contents (names entering/leaving READY, state flips, regime changes). It also covers input derivation, cost, and the relationship to the free poll. An agent has everything needed to call it correctly and interpret results.

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

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

The single parameter `since` is documented in the schema, but the description adds critical context by explaining its origin (state_hash from a previous /api/board/state poll), its format (16 hex chars), and its role in the polling loop. This goes beyond the schema's bare definition.

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 it returns changes on the board since a prior state_hash, specifying the exact types of changes (READY pool entries, trend-state/light/leadership/hold-band flips, regime/permission-ladder moves). It explicitly distinguishes itself from the free /api/board/state poll and the broader board tools, making its purpose 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 usage guidance: 'This is the loop primitive: poll the free hash, call this only when it moves.' It also explains the free response on unchanged hash and clarifies the relationship with /api/board/state, effectively telling an agent when to call this tool versus relying on the free endpoint.

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

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

With no annotations provided, the description carries the burden. It discloses data delay ('one market day delayed'), the inclusion of a regime mode indicating actionability, and the pay-per-call nature of the live sibling. These are meaningful behavioral traits that help an agent set expectations, though it does not mention rate limits or auth requirements.

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

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

The description is a single, dense sentence that packs in all essential details: two lanes, specific scores, flags, regime mode, free tier delay, and the live alternative. It front-loads the core purpose and each clause earns its place, with no 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 no output schema and no parameters, the description covers the key output elements (scores, flag, note, regime) and the critical distinction between free and live versions. It provides enough context for an agent to decide to call this tool and understand what it will receive.

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

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

The input schema has zero parameters, so the description need not explain parameter behavior. Baseline for 0 params is 4, and the description adds no competing information. It could explicitly state 'takes no parameters' but that is unnecessary given the empty 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: 'Today's ranked buy-list candidates per book across two lanes' and mentions specific outputs like scores, leadership flag, and entry-window note. It distinguishes from the sibling get_buy_list_live by naming it explicitly, and from other board tools by focusing on buy-list candidates.

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 provides clear context for when to use this tool vs. the live sibling: 'Free tier: one market day delayed. Live sibling (x402, pay-per-call): get_buy_list_live.' This implies the free version is for delayed data and the live one for real-time needs, but it does not explicitly state exclusions or alternative non-live tools.

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

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

No annotations are provided, so the description carries the burden. It discloses that this is a paid call ($0.02 USDC via x402) and implies a wallet requirement. It also indicates the intraday/live nature and that candidates are shown while entry windows are open. It does not mention rate limits or failure modes, but given zero parameters and no output schema, it provides sufficient 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 compact and contains no fluff, but the first sentence is slightly clunky with 'Live intraday get_buy_list' as a noun phrase. It packs three pieces of information (live status, delay comparison, cost) into three short sentences, earning a high score though not a perfect 5.

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

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

For a zero-parameter tool with no output schema, the description covers the essential aspects: what it does, when to use the alternative, and cost. It does not describe the response format, but that is often acceptable when no output schema exists. The reference to READY/SETUP is domain-specific but provides meaningful context.

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

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

The tool has zero parameters, and the schema trivially covers 100%. Baseline for 0 parameters is 4. The description adds context about what the tool returns (ranked candidates) but does not need to explain parameters since there are none.

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 it returns live intraday ranked buy candidates with entry windows still open (READY/SETUP). It differentiates from the sibling get_buy_list by emphasizing the 'live' and 'intraday' nature, which distinguishes it from the delayed free version.

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

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

The description explicitly contrasts with get_buy_list: if no wallet, use the free delayed version. This implies the live version requires a wallet/cost and is for real-time needs. However, it does not explicitly state 'use this when you need real-time data' beyond the name and context.

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

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

With no annotations, the description carries the disclosure burden. It does add useful behavioral context by naming X-Session-Id / Mcp-Session-Id as the session tie-in, and 'get' implies a read. It stops short of describing response shape, error behavior, or what happens when no session is supplied, so transparency is partial.

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 compact phrasal sentence with no filler; each part adds either scope, identifier, or context. The 'Storefront:' prefix is slightly cryptic but not wasteful.

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

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

For a zero-parameter read, it covers the essential facts: resource, scope, and required session identifiers. But there is no output schema or annotations, and the description does not explain return contents, errors, or how the cart relates to sibling storefront concepts, leaving notable gaps.

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

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

The input schema has zero parameters and 100% trivial coverage, so there are no parameter semantics for the description to add. The header mention goes beyond the empty schema and earns the zero-parameter baseline.

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 identifies the resource ('cart'), the scope ('the session's cart'), and the relevant domain ('Storefront'), naming the session identifiers that anchor it. This distinguishes it from cart-mutating siblings like add_to_cart, remove_from_cart, and update_cart_item, though the verb is only implicit in the tool name.

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 session-scoped wording implies the tool is used when the current session's cart is needed and the header names signal the prerequisite identifier. However, it gives no explicit when-to-use/when-not-to-use guidance or alternatives such as get_buy_list or checkout_handoff.

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

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

With no annotations provided, the description carries the full burden and does so well: it reveals this is a preview/trimmed slice, live (not delayed), and what data points are included (trend distances, tape lights, ATR%, etc.). It manages expectations by stating it is 'a state map, not a ranking or advice.' It does not mention auth, rate limits, or errors, but for a zero-parameter tool, this is strong 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 tight three sentences. The first sentence defines what it is, the second elaborates on the state map contents, and the third clarifies what it is not and points to the full version. Every sentence adds value. It uses technical terms (ATR%, volume z-score) that are dense but relevant. Slightly heavy on jargon but not verbose.

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 no output schema or annotations, the description effectively conveys what data to expect: top-3 coins, BTC anchor, gate regime, breadth counts, and a list of per-coin fields. It also points to the full board for completeness. It does not detail the output format (e.g., JSON structure), but for a no-parameter tool, it covers the essential 'what' and 'why use this vs. alternative' well.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it doesn't, but it does explain the output structure, which is helpful. It correctly adheres to the rule that with no params, a score of 4 is appropriate.

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

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

The description clearly states a specific verb+resource+scope: 'crypto day-state PREVIEW' of 'the top-3 of 81 Robinhood-tradable coins by trend rank' plus additional indicators. It distinguishes itself from siblings by explicitly differentiating from the 'full 81-row board' available via get_crypto_day_live, and clarifies what it is not ('not a delayed copy', 'not a ranking or advice').

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 explicitly names the alternative for the full board: 'Full 81-row board: get_crypto_day_live (x402, pay-per-call).' This gives clear context on when to choose this preview vs. the pay-per-call full version. However, it does not discuss other siblings like get_crypto_night or when to use them, so it is not exhaustive but adequate.

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

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

No annotations are provided, so the description carries the transparency burden, and it does: it discloses the $0.005 USDC per-call cost, the ~5-minute publish interval, and the 'when the market moved' condition. It also specifies scope (all 81 coins) and output nature (state map not ranking). It does not mention rate limits or response format, but the key behaviors are 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 front-loaded with the core value proposition, then packs a dense list of included metrics, followed by update cadence, a clarification, an alternative, and pricing. Each clause adds information and nothing feels repetitive or 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?

For a zero-parameter tool with no output schema and many siblings, the description gives enough context to decide when to call it and what to expect: full coin list, metrics, freshness, pricing, and a fallback for users without a wallet. The enumerated fields compensate for the absence 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?

The tool has zero parameters, so the baseline is 4 and there is no parameter documentation burden on the description. The description implies a no-argument interface by describing the fixed scope of the returned board. No additional parameter semantics are needed.

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

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

The description identifies a specific resource: the full 24/7 crypto day-state board covering all 81 Robinhood-tradable coins, and enumerates the metrics included. It distinguishes itself from get_crypto_day by noting the full board versus a free top-3 preview. Though it lacks an explicit verb, the name and 'board' phrasing make the retrieval action clear.

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

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

It gives an explicit routing rule: 'No wallet? get_crypto_day is a free live top-3 preview,' implying this tool requires a wallet or payment. It also clarifies that this is a state map, not a ranking, telling an agent when this tool fits. However, it does not contrast against the many other live crypto siblings like get_crypto_night_live or get_crypto_trend_live.

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

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

No annotations are provided, so the description carries the full disclosure burden. It notes 'A state read, not advice' which implies non-mutating, but lacks detail on output format, error behavior, or rate limits. The promotional language about study results adds noise but does disclose the refutation aspect.

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 verbose and promotional, including study results and fee-tier comparisons that do not directly help an agent understand the tool's operation. It lacks a clean, front-loaded structure and contains redundant marketing phrases, making it less concise than needed.

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 no parameters and no output schema, the description does enumerate key elements (coin, regime gate, phases, receipts) but not their exact structure or how to interpret them. It's sufficient for a high-level understanding but leaves ambiguity about the return payload.

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 parameters and 100% schema coverage (empty object), the description doesn't need to add parameter details. The baseline for zero parameters is 4, and the description doesn't introduce any parameter-related confusion.

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 provides an overnight crypto continuation preview, specifying the #1 session-momentum coin, BTC regime gate, phases, and study receipts. It explicitly differentiates from the sibling get_crypto_night_live by noting the full top-5 is available there, making the purpose specific.

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

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

The description implies this is the preview version and get_crypto_night_live is the pay-per-call full top-5, but it doesn't explicitly state when to use this tool versus other sibling tools like get_crypto_day or get_crypto_trend. The guidance is limited to mentioning the live 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?

With no annotations, the description carries the full burden. It discloses a $0.001 USDC per call fee, states a ~15-minute refresh interval, and implies a wallet may be required by mentioning it in context of the free preview. It does not describe side effects beyond being a read operation, which is appropriate.

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

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

The description is a single sentence but is structured with semicolons and dashes, front-loading the main purpose and then detailing contents. Every phrase adds value, but its length is a bit dense for a single sentence, so a 4 rather than 5.

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 thoroughly covers what the tool returns, including the universe coin count, regime gate, phase clock, receipt contents, refresh rate, and cost. With no output schema, it conveys all necessary return information. It is complete for a zero-parameter read tool.

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

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

The tool has zero parameters, so the schema is trivial. The description does not need to add parameter details, and it doesn't contradict any schema. With no parameters to document, a baseline of 4 is appropriate.

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

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

The description clearly states the tool provides 'the FULL overnight continuation read' with a detailed list of what it returns (top-5 coins, BTC regime, phase clock, eligibility counts, receipts). It distinguishes from the sibling get_crypto_night, which is a free preview trimmed to the #1 coin.

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

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

The description implies when to use the full version versus the free preview by mentioning 'No wallet? get_crypto_night is a free live preview'. It also mentions cost and refresh interval, but does not explicitly state 'use this when full details are required' or exclude other cases. The comparison with the sibling tool provides clear context.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses the scan is live, trimmed/preview-only, not investment advice, and that the pattern grading is forward-graded on crypto while backtest-confirmed on equities. It also signals the commercial context by mentioning the paid version, which helps set expectations about scope and reliability.

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

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

The description is three tight sentences: the first front-loads exactly what the tool returns, the second explains its purpose as a paid-scan preview, and the third adds an important methodological disclaimer. Every clause earns its place, and the sibling tool reference is efficiently appended.

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

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

For a zero-parameter, no-output-schema informational tool, the description is complete: it states the counts, fields, grading scope, live nature, preview limitation, disclaimers, and the paid alternative. An agent can call this tool and interpret its result without needing additional context.

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

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

The input schema has zero parameters with 100% coverage, so there is no parameter burden for the description to bear. The baseline for a no-parameter tool is 4, and the description appropriately adds no confusing parameter 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 identifies the tool as a preview of a crypto SETUP scan, specifying it reports how many of 81 Robinhood-tradable coins show one of two washed-shape patterns and lists the top-3 hits with specific fields (grade, GO, fuel vs BTC, room). It also differentiates itself from the sibling get_crypto_setups_live by labeling this one a 'PREVIEW' and 'trimmed slice' of the paid version.

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 states the tool is a 'LIVE trimmed slice of the paid scan, so you can judge the read before paying', giving clear context for when to use it. It names the alternative get_crypto_setups_live for the full hit list, though it could more explicitly state 'use this for preview; use live for full results'.

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

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

With no annotations present, the description carries the full burden — and it discloses a lot: exact pricing ($0.05 USDC per call via x402, pay-per-call), recompute cadence (~5 min, 24/7), and an honest methodology caveat that shapes were backtest-confirmed on equities but are only forward-graded on crypto. Telling the agent the read is paid and not crypto-backtested is precisely the behavioral context annotations would otherwise need to supply.

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

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

Four sentences, each earning its place: the scan/output spec, the freshness cadence, the backtest methodology caveat, and pricing plus the free preview alternative. The core action is front-loaded in sentence one, 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 zero-parameter, paid scanner with no output schema, the description covers the central decisions: what gets scanned, what a hit contains, freshness, cost, and how to preview via the free twin. The remaining gap is that domain terms like GO, fuel multiple, grade, and room are listed without definitions, and no output schema exists to fill that in.

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

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

The input schema is empty (zero parameters), so there is nothing for the description to add about arguments — the 0-param baseline of 4 applies. It instead previews the read's contents (GO, fuel multiple vs BTC, grade, room, setup column), which is output-side context rather than parameter semantics.

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

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

The description names a concrete verb and resource — scan all 81 Robinhood-tradable coins — and specifies the exact setup shapes sought (daily uptrend + washed-out 5-minute tape). It distinguishes itself from sibling get_crypto_setups by calling itself the paid full-universe read versus the free hit-count/top-3 preview.

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 explicitly names the free twin get_crypto_setups as a preview option 'so you can judge it before buying', giving the agent a concrete route to the cheaper alternative. It does not cover when to prefer other live crypto probes like get_crypto_day_live, but the free-twin routing addresses the main decision an agent faces for this paid 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?

Discloses evaluation on UTC daily closes, the exact delay (one completed close), evaluation every calendar day including weekends, and the signal_close_date stamp. Also clarifies it is rules-based rather than raw price data. With no annotations, this provides substantial 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?

Three tightly scoped sentences cover output components, evaluation cadence, delay, and live alternative without fluff; each clause adds informational value.

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?

Despite lacking output schema, the description enumerates the key output fields (LONG/CASH states, trend gates, price, day change, signal_close_date) and explains the operational context (UTC closes, calendar-day evaluation, free-tier delay), making it self-sufficient for a zero-param 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?

Tool has zero parameters; empty schema with 100% coverage, so description adds no parameter semantics. Baseline 4 applies for zero-param tools.

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?

Clearly states it provides Bitcoin and Ethereum trend signals with LONG/CASH states, 50-day and 200-day gates, evaluated on UTC daily closes, and distinguishes itself from raw price data. The explicit contrast with get_crypto_trend_live differentiates it from the 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?

Explicitly identifies the free tier's one-close lag and points to get_crypto_trend_live for the newest close, explaining the tradeoff. Clarifies it is a risk-on/risk-off verdict, not raw price data, guiding appropriate use.

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

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

With no annotations, the description carries the burden of disclosing costs ($0.005 USDC per call), update frequency (daily including weekends), and output stamping (close used). However, it does not explicitly state that it is a read-only operation, nor does it describe potential errors or rate limits. The mention of 'x402' is cryptic for some users.

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 four short sentences each adding relevant information: core function, timeliness, free alternative, and pricing. It is front-loaded with the main purpose. Minor repetition of 'get_crypto_trend' and a casual tone ('No wallet?') prevent a 5.

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 no output schema, the description should explain what the tool returns (e.g., the trend value or signal). It mentions the close stamp but never explicitly states the output type or format. It covers cost and update timing, but leaves the return value ambiguous, so it is only minimally complete.

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

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

The tool has zero parameters, so schema coverage is 100% by default. Per the rubric, a baseline of 4 applies. The description adds no parameter-specific meaning (there are none), but that is not needed.

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

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

The description clearly states the resource (crypto trend) and the timing (newest completed UTC daily close), and it distinguishes from the sibling 'get_crypto_trend' by emphasizing timeliness and cost. However, it relies on the sibling's meaning for 'trend' and does not fully explain what the tool returns, so it is not 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?

The description gives practical guidance: it mentions the free alternative ('get_crypto_trend is free') and when to use this paid version (when you need the newest close, not one close behind). It also notes it updates every calendar day, implying freshness. There is no explicit 'use this when X, otherwise Y', but the context is clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that data is delayed, decays in minutes, and is not suitable as a trading input—critical context. It lacks explicit detail on output format or edge cases but provides strong caveats that go beyond a simple summary.

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

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

The description is dense but effectively front-loaded with the core purpose ('Yesterday's day-trade state map'). It packs a lot of detail into a compact space, though some acronyms (GO, FUEL, ROOM) are unexplained, slightly reducing 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?

Given no output schema or annotations and moderate complexity, the description covers the content, staleness, and live alternative. It could be more complete by defining key terms (e.g., ROOM) or outlining the exact response shape, but the description provides enough context for an agent to decide whether to invoke it and what to expect.

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

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

The tool has zero parameters and the schema is empty, so there is no parameter burden. The description appropriately focuses on the output and limitations rather than parameter details, aligning with the baseline for parameterless tools.

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 what the tool provides: a 'Yesterday's day-trade state map' with a specific grid of indicators (price/RSI/MACD, 5m-1D) and trading states (GO, FUEL, ROOM) across ~70 liquid names. It distinguishes itself from the live sibling by explicitly labeling the live version as a separate 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?

It explicitly says the free delayed tier is a 'schema/shape preview, not a trading input' and mentions that day states decay in minutes, implying use the live sibling when actual trading decisions are needed. It also names the live alternative directly, giving clear usage 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?

With no annotations, the description carries the full transparency burden and does so thoroughly. It discloses the ~5 minute refresh during market hours, the $0.01 USDC cost per call, the 'ext:true' flag meaning late, and the state-map vs ranking behavior. This goes well beyond basic expectations.

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

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

The description is dense and front-loaded with the core purpose, but it contains four sentences with multiple clauses. Each sentence adds value, yet the length is slightly more than the leanest possible. Overall, it is well-structured with no 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?

For a zero-parameter, no-output-schema tool, the description is highly complete. It covers what the data map contains, refresh cadence, cost, the meaning of 'ext:true,' and a fallback alternative, giving the agent all essential context to select and invoke the tool correctly.

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

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

The tool has zero parameters, so there is no schema to clarify. The description adds rich context about the data and behavior, which compensates for the absence of parameters. A baseline of 4 is appropriate for zero-parameter tools.

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 explicitly defines the tool as a 'LIVE day-trade state map' with a concrete feature list (18-cell lights grid, GO, FUEL, efficiency, ATR%, vs-SPY, entry-window state, ROOM) and explicitly contrasts it with a ranking and with the sibling get_day_board. This makes its purpose unmistakable and distinguishes it from similar 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 provides explicit usage guidance: it tells the user to use get_day_board instead if they have no wallet ('No wallet? get_day_board is yesterday's map, free'), implying this tool requires payment and is for live data. It also clarifies that it is 'not a ranking,' telling the agent it should not be used for ranking purposes.

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

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

With no annotations present, the description carries the full behavioral disclosure burden, and it does so strongly. It discloses the authentication/licensing requirement, refresh cadence, that the payload is identical across subscribers, the 'research, not advice' disclaimer, and that engine fields are self-described in the payload's schema block. This gives an agent accurate expectations for calling the tool.

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

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

The description is longer than strictly necessary and has some promotional wording, but nearly every sentence conveys a useful operational detail: subscription, header, refresh rate, filter, payload schema self-description, and version date. It is front-loaded with the core purpose, so while it could be tightened, it remains effective.

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 feed tool with zero required parameters and no output schema, the description is remarkably complete. It covers authentication, payload contents, comparison to get_full_board, filtering, refresh behavior, and how to interpret the engine fields via the payload's schema block. Nothing critically needed to invoke the tool 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 only parameter, symbols, is already fully documented in the input schema with coverage at 100%. The description merely repeats 'Optional symbols[] filter' without adding any new meaning such as formatting, case sensitivity, or behavior for invalid tickers. The schema is doing the heavy lifting, so baseline 3 is appropriate.

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

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

The description states a specific resource — the engine-grade live board from coil.trade — and explicitly contrasts it with get_full_board by saying 'everything in get_full_board PLUS' engine-specific fields. It lists concrete deltas (stop/target levels, risk-reward, buy_score, conviction, lane, etc.), so an agent can clearly identify what this tool uniquely returns.

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 usage context: it requires an active Coil Live subscription, requires sending the license via X-License-Key, supports an optional symbols[] filter, and refreshes about every 5 minutes. It names get_full_board as the base alternative, but it does not explicitly state when to prefer other sibling tools or when not to use this one beyond the subscription prerequisite.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It mentions 'instant, no fee,' which appears to describe the digital delivery option rather than the tool's behavior. It does not disclose whether this is read-only, what inputs are used, error conditions, or any 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 extremely short, but this is under-specification rather than effective conciseness. The fragment 'Storefront: digital delivery — instant, no fee' contains no actionable structure, no front-loaded purpose, and leaves out critical information needed to call the tool.

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

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

With one required parameter, no output schema, no annotations, and a very terse description, the tool is far from completely specified. The description does not explain what the tool returns, how product_ids should be used, or any context to differentiate it from the many get_* siblings.

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

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

The schema has one parameter, product_ids, with 0% description coverage, and the tool description does not mention it at all. The agent is left to infer that product_ids are the products for which fulfillment options are retrieved, but the description adds no semantic value beyond the parameter 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 'Storefront: digital delivery — instant, no fee' gives some contextual scope (storefront, digital delivery, no fee) but lacks a verb or explicit statement of what the tool does. It vaguely implies fulfillment options for digital delivery, but the agent must infer the operation from the tool name rather than 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?

There is no guidance about when to use this tool versus any of the many sibling tools, no conditions, and no mention of alternatives. The description is purely a label, so the agent cannot determine when this tool is appropriate.

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

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

With no annotations, the description carries the full disclosure burden and does more than just say 'read'. It reveals that the result is a single live payload, that fields are self-describing and may appear upstream before docs update, and that each call costs $0.25 USDC. It does not mention auth or rate limits, but the essential behavioral traits are 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 dense but each sentence earns its place: scope, component list, per-name fields, dynamic schema behavior, and pricing. The key purpose is front-loaded, and no filler or structural repetition exists.

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

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

For a no-input tool with no output schema, this is nearly complete: it names all payload sections, describes embedded self-describing metadata, and states the cost. It is only lightly limited by not mentioning potential failures, latency, or payment mechanics, but those are reasonably inferable.

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

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

There are zero parameters and schema coverage is 100% by default, so there is nothing to clarify about arguments. The description focuses on the payload shape instead, and the mention of a self-describing schema block is useful.

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?

Starts with 'The complete LIVE board in one payload', naming the exact resource and scope—every scored name across S&P 500, Nasdaq-100, and macro, plus sector, buy-list, regime, and crypto books. This clearly differentiates it from sibling single-read tools like get_stock_read_live or get_sector_read_live, and 'flagship read' reinforces its unique role.

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 context that this is the all-encompassing board read and says there is 'no free counterpart', implying it is the go-to for a complete snapshot. However, it never explicitly states when to choose it over the sibling tools or when not to use it, leaving the agent to infer the 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?

With no annotations provided, the description carries the full disclosure burden and succeeds: it lists every returned field (hold strength 0-100, maturity-late flag, gap-risk grade, watch_flags and their exact deterioration conditions), states it returns published state only, clarifies it is impersonal and never reads entry/size/account, and discloses the free-tier delay. This is exemplary behavioral disclosure for a read-only tool.

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

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

Every sentence earns its place — the punchy opener ('THE SELL-SIDE READ') front-loads the purpose, followed by return fields, watch_flag conditions, crypto special case, formatting, and the live sibling. It is a dense single paragraph rather than structured bullets, so it sacrifices scannability, but there is 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?

Given one parameter, no output schema, and no annotations, the description is remarkably complete. It compensates for the missing output schema by detailing every returned field and the watch_flag conditions, covers symbol formatting, the crypto exception, the free-tier delay, and the live alternative. Nothing an agent needs to invoke it correctly is left unclear.

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

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

Schema coverage is 100% for the single parameter, so the baseline is 3. The description adds real value beyond the schema by specifying the comma-separated format, the up-to-10-symbol limit with an example (NVDA,AMD,BTC-USD), and the special crypto IN|CASH behavior. That lifts it above baseline.

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

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

The description states a specific verb ('get'), resource (hold state), and a precise purpose: the sell-side read of whether the case for a name you already hold is intact or deteriorating. It distinguishes itself from siblings by naming the live counterpart get_hold_state_live and enumerating the exact fields returned. No ambiguity about what this tool does.

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

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

The phrase 'for a name you already hold' clearly signals this is for existing positions, and it differentiates the free tier (one market day delayed) from the live sibling get_hold_state_live. It also notes the crypto special case for BTC-USD/ETH-USD. It lacks explicit 'use X instead when...' exclusions against get_stock_read or get_crypto_trend, but the held-name framing and live-sibling reference give solid usage context.

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

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

With no annotations, the description carries the full burden. It discloses that this is a read operation ('read'), that it never reads your entry or size, and that it charges $0.005 USDC per call. It also notes the live intraday nature. While it does not mention error handling, rate limits, or authentication requirements, the key behavioral facts (pricing, read-only nature, scope) are transparently stated. A small gap remains regarding what exactly 'read' implies in terms of data access.

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 paragraph but packs multiple useful facts without fluff. It front-loads the core purpose, then follows with capacity, behavior, fallback alternative, and pricing. Each sentence contributes value. It is slightly dense but not verbose, earning a 4 rather than a 5 because it could be organized into clearer bullet points.

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

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

Given the tool's simplicity (one parameter, no output schema), the description fairly completely covers what the agent needs: what data is returned (via the enumerated fields), the pricing, the capacity, and the alternative. It does not detail error scenarios or rate limits, but for a 1-parameter live read with a known sibling, this is adequate. A 4 reflects minor omissions rather than significant gaps.

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

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

The schema fully describes the single parameter `symbol` (including comma-separated up to 10 tickers), and the description only repeats that capacity ('Up to 10 symbols in one call'). No additional semantic value is added beyond the schema. Per the rubric, with >80% coverage the baseline is 3; the description adds no extra meaning for this parameter.

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

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

The description opens with a specific verb+resource: 'Live intraday get_hold_state' and explicitly clarifies it is the 'SELL-SIDE read on names you already hold.' It enumerates the exact outputs (trend state, hold strength, readiness, etc.), which distinguishes it from the delayed sibling get_hold_state by contrasting price and delay. This gives an agent a precise understanding of what the tool does and how it differs from its closest 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 tells when to use it versus the alternative: 'No wallet? get_hold_state is the same read, free, one market day delayed.' This provides an explicit condition for choosing the non-live sibling. It also states capacity ('Up to 10 symbols in one call') and clarifies it is not for trade instructions ('Conditions, never instructions'), making the appropriate use case 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?

With no annotations, the description discloses the active subscription requirement (X-License-Key), versioning behavior, and that the payload indicates when rules changed. It does not explicitly state the tool is read-only or describe error behavior for missing/invalid keys, but the core behaviors are 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?

Three sentences front-load the purpose, list contents, and convey key constraints (subscription, versioning) with no redundancy. Every sentence adds value and stays focused.

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

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

For a zero-parameter retrieval tool with no output schema, the description covers purpose, contents, auth, and versioning. It could be more explicit about return format, but the mention that the payload indicates when rules changed gives sufficient context for the agent to select and invoke the tool.

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

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

The tool has zero parameters, so schema description coverage is trivially 100%. No parameter details are needed, and the description appropriately focuses on the tool's purpose. A baseline of 4 for zero-parameter tools applies.

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

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

The description clearly identifies the tool as the versioned rulebook for the Coil Live engine feed, listing its contents (cycle order, exits-first, stop derivation, day-lane rhythm, sizing, fail-closed rules). This distinguishes it from sibling tools that provide data feeds or boards.

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 states the tool is what the agent runs against get_engine_feed, implying usage to understand execution rules. It also mentions the subscription prerequisite, but does not explicitly list when not to use it or name 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?

Without annotations, the description must carry behavioral info. It discloses that the tool itself is free, that other live tools require a subscription, and that failing closed occurs on non-payment. It doesn't mention side effects beyond that, but it covers the key behavioral caveat. A 4 is appropriate given the absence of 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 a single long sentence that packs in multiple aspects (connection, licensing, cadence, fail-closed behavior). It is dense but somewhat run-onholish. It is not particularly concise or front-loaded; key information is mixed together. It could be more structured into distinct clauses or sentences for 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?

The description covers the connectivity and subscription context thoroughly, but it does not explain what the tool returns or how it fits into the workflow besides setup. With no output schema, the agent might be unclear about the tool's output. It lacks explicit mention of return value or operational effects beyond instructions.

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

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

There are no parameters, and schema coverage is 100% (empty). The description doesn't need to explain parameters, but it does add meaning by explaining the tool's role and the context of the live subscription. Since there are no parameters, the baseline for schema coverage is high, so this is slightly above baseline due to added value about the tool's purpose.

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 explicitly states the tool's purpose: 'how to connect this agent to Coil Live' and clarifies it is 'free to call'. It also implies the tool provides setup configuration informationches. It distinguishes from sibling tools by focusing on connection/licensing, while other tools are data-fetching. However, it does not directly state what the tool returns, leaving some ambiguity.

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 explicit guidance: what subscription unlocks (every *_live tool, engine_feed, live_rules), how to send the license key, recommended cadence, and behavior when payment stops. It clearly frames when to use this tool (for connection setup) and contrasts with other toolscripter.

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

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

With no annotations, the description carries the behavioral burden, and it does disclose meaningful behavior: the output includes a full score read, an awareness block with sector money flows, coiled setups with coil_score range, and rows shaped by the payload's schema block. It also notes the date after which the awareness block is included. It does not mention latency, auth, or rate limits, but for a zero-parameter read the content disclosure is strong.

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 front-loads the core ranked-list result and then adds the sibling, the awareness-block change, and the schema contract in compact sentences. Every sentence adds information, though the dense jargon ('x402', 'coverage', 'board-tier') takes some decoding.

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 no output schema and no annotations, the description provides the main contract: top 10 per book, ranking criterion, full score read, awareness block components, coil_score range, and a pointer to the payload schema for field names. It leaves some domain terms undefined (book, leadership names, coverage), but an agent can still understand what the tool returns and how it differs from the live variant.

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

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

The tool has zero parameters, so there is nothing for the description to elaborate beyond the empty input schema. Per the baseline rule for no parameters, no additional parameter semantics could improve this definition.

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

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

The description opens with a clear, specific deliverable — the top 10 leadership names per book ranked by opportunity score — and defines the selection criteria (confirmed uptrends) and the fields returned. It also distinguishes itself from the live sibling by name and cost caveat, though it does not contrast with other list-like siblings such as get_buy_list or get_rotation.

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 only usage signal is the mention of a live sibling with a pay-per-call cost, which implicitly suggests the non-live tool for routine or cost-conscious reads. No explicit when/when-not guidance is given, such as 'use this for the daily snapshot, use live for intraday'.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses that data is recomputed on the intraday board, that a live awareness block is included with sector money flows and coiled setups, and that each call costs $0.01 USDC via x402. It also implies a wallet requirement through the 'No wallet?' alternative.

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 sentences, each earning its place: the core result and freshness, the free alternative, and the extra payload plus cost. The key differentiator is front-loaded and there is no wasted wording.

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

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

For a zero-parameter read tool with no output schema, the description is complete: it states what is returned, how fresh it is, what extra data the live version carries, how much it costs, and which sibling to use if payment is not available.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific detail because none is needed; the input schema already fully covers the empty parameter set.

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 operation: returning today's top 10 leadership names per book by opportunity score, computed on the intraday board. It clearly differentiates this live variant from the sibling get_market_leaders by calling out the delayed free version as the same read.

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 explicitly names the alternative get_market_leaders and gives the condition for choosing it: 'No wallet? get_market_leaders is the same read, free, one market day delayed.' This tells an agent when to use this tool versus a direct sibling, and the pricing detail clarifies the cost tradeoff.

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

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

With no annotations provided, the description carries the full burden of explaining behavior. It discloses that the tool is a read of the market tape, returns structured regime data, and operates with a one-market-day delay on the free tier. It also details the posture fields returned for each book, which is useful behavioral context beyond the name alone.

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

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

The description is dense but every sentence earns its place: purpose, output contents, usage timing, tier limitation, live alternative, and field-level details. It is front-loaded with the core concept and does not waste words. The structure is easy to scan and decision-relevant.

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

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

For a zero-parameter read tool with no output schema, the description is remarkably complete. It enumerates the books covered, the regime posture fields, the free-tier delay, and the live sibling. An agent can confidently call this tool and understand what to expect without additional context.

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

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

The tool has zero parameters, so the schema leaves nothing undocumented. The description adds value by explaining what the returned regime verdict represents and how it is structured across books. This meets the baseline for a no-parameter tool and slightly exceeds it by providing output context.

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 defines the tool as a top-down market read that returns a regime verdict, mode, and permission ladder across multiple books. It also names the live sibling, get_market_regime_live, and differentiates this tool as the free, delayed version. The verb and resource are specific, making the purpose 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?

The description explicitly says to check this tool before acting on any name-level signal, which is strong usage guidance. It also distinguishes the free delayed tier from the pay-per-call live sibling, giving the agent a clear alternative. It does not fully spell out when to choose the live version vs. this one, but the context is clear.

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

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

With no annotations, the description carries full burden. It discloses pricing ($0.005/call), refresh frequency (~5 min), timing (market hours), and implies it's a read operation ('same read'). It could also mention rate limits or behavior outside market hours, but the provided context is strong.

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

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

Two sentences pack core functionality, usage guidance, pricing, and alternative. Every word earns its place 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?

Covers what the tool returns (regime verdict, mode, permission ladder), when it updates, cost, and the free alternative. No output schema exists, but the description sufficiently explains the output and usage context.

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

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

The tool has zero parameters and the schema confirms this with an empty properties object. Baseline for 0 params is 4; the description adds no parameter details but none are needed.

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

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

The description clearly states the tool's function: it computes the live intraday market regime verdict, mode, and permission ladder. It distinguishes from the sibling get_market_regime by specifying 'live' and '~5 min in market hours'.

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 explicitly names the alternative get_market_regime for delayed/free access, and labels this tool as 'the loop primitive, priced to be polled,' indicating when to use it in a polling loop rather than the delayed version.

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

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

With no annotations, the description carries the behavioral burden. It discloses that data is delayed by one market day on the free tier and enumerates what the payload includes. It does not explicitly state that the operation is read-only or discuss rate limits, but the 'get' prefix and 'read' framing make this low-risk and clear enough.

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 front-loads the core purpose and then adds the tier/delay and live alternative. The 'Now includes...' sentence is slightly promotional and could be trimmed, but it still adds useful content detail without becoming bloated.

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

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

For a zero-parameter tool with no output schema, the description gives a solid inventory of what the response contains and notes the delay and live alternative. The final 'coverage' reference is vague, but overall the agent has enough context to call it correctly and interpret the result.

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

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

The tool has zero parameters and an empty schema, so there are no parameter semantics to document. The description correctly implies that no input is needed beyond simply calling the tool.

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

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

The description names a clear resource ('morning brief') and states it gives 'the whole market read' with enumerated sections: regime verdict, top-5 buy candidates, gainers/losers, and crypto trend-gate state. It also distinguishes itself from get_morning_brief_live by calling itself the 'Start here' free-tier version.

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 explicitly says 'Start here' and contrasts the free delayed tier with the live pay-per-call sibling get_morning_brief_live. This gives an agent a clear rule: use this tool for the free, delayed market snapshot, and use the live sibling when real-time data is needed.

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

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

There are no annotations, so the description carries the burden. It discloses the live intraday nature, the contents of the response, the wallet/payment requirement via 'No wallet? get_morning_brief is free,' and the explicit $0.02 USDC per-call cost via x402. It stops short of describing failure modes or precise output format, but for a read-style 0-parameter tool the key behaviors are well 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 compact and front-loaded with the tool's purpose. Each sentence adds useful information: contents, free alternative, included awareness read, and cost. It is slightly choppy and repeats 'get_morning_brief,' but no sentence 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?

For a 0-parameter, no-output-schema tool, the description covers the essential selection and invocation context: what data is included, live vs. delayed, cost, and the free alternative. It could add explicit wallet-required wording and a note on expected response shape, but it is largely sufficient for an agent to decide and 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?

The tool has zero parameters, so parameter semantics are largely moot and the baseline is 4. The description adds useful context about what the single call returns, making it clear that no parameters are needed to access this bundled live brief.

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 this as the live intraday version of get_morning_brief and enumerates its contents: regime, top-5 candidates, movers, crypto gate, and a live awareness read. It distinguishes itself from the sibling get_morning_brief by emphasizing 'live' and 'current session' versus the delayed free version.

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 explicitly contrasts with get_morning_brief: 'No wallet? get_morning_brief is free, one market day delayed,' making the when-to-use vs. when-not-to-use decision explicit. The 'current session' wording clarifies that this tool is for live intraday needs, while the paid/free distinction guides budget-aware choices.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently says 'NotOffered', which informs the agent that the tool will not provide orders, and adds that receipts/licence keys are external (Gumroad). It does not describe what actually happens on invocation (e.g., error or empty response), but the core behavior is disclosed.

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

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

The description is a single concise sentence with no unnecessary words. However, its brevity comes at the cost of essential operational information; it is more of a status notice than a tool description, so it earns only a mid score.

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

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

Given that the tool is marked 'NotOffered', the description explains the basic situation and directs users to Gumroad. But it leaves the 'limit' parameter entirely unexplained, provides no output schema, and does not reference any sibling tool as an alternative, making it incomplete for an agent deciding how to proceed.

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

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

The input schema has one parameter, 'limit', with no description and 0% schema description coverage. The description does not mention 'limit' at all, leaving the agent with no understanding of what this parameter controls or whether it is even accepted.

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 'Storefront: NotOffered' which indicates the tool is unavailable, and mentions Gumroad as the home of receipts and licence keys. However, it lacks a specific verb or action describing what the tool actually does when invoked, and it does not clearly distinguish itself from sibling tools like get_order_status.

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 hints that receipts and licence keys should be obtained from Gumroad rather than this tool, implying it should not be used for those purposes. It does not, however, specify when to use this tool versus any sibling alternative, nor does it state that the tool should simply not be called.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions only that the tool is NotOffered and defers to get_orders, but says nothing about what happens if invoked, whether it errors, requires auth, or has 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 a single front-loaded sentence with no wasted words. It clearly signals unavailability first and then gives a redirect, which is appropriately concise for what appears to be a stub or disabled tool.

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

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

For a disabled-tool redirect, the description may be minimally sufficient: it tells the agent the tool is not offered and where to look instead. However, it does not explain why it is not offered, what get_orders actually returns, or whether the tool is ever usable outside the Storefront context.

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% and the description adds no meaning to the required order_id parameter. There is no compensation for the schema's lack of parameter documentation, so the agent gains no insight into how to fill the argument.

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 does not state what get_order_status does; it only declares 'Storefront: NotOffered' and directs the agent to get_orders. While this communicates unavailability, it lacks a functional verb+resource statement and relies on the tool name to imply purpose.

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

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

The description explicitly marks the tool as NotOffered and points to get_orders as the alternative. This gives clear guidance that the agent should not select this tool and should use get_orders instead, even though it does not specify exact selection conditions.

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

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

With no annotations, the description must carry the behavioral burden. The 'no customer accounts' disclosure is a genuine data-model trait that prevents an agent from expecting account personalization. Yet it does not state what the call returns, whether it is read-only, or any side effects; those are assumed from the name.

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

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

The definition is two short clauses, front-loads the domain, and wastes no words. It is appropriately compact for a zero-parameter tool, though the fragment style sacrifices some 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 zero-parameter read tool, the description is almost sufficient: it gives the domain, guest scope, and account constraint. It still omits an explicit statement of return value or behavior, so the agent must rely on the tool name to understand the result.

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

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

The input schema is empty with 0 parameters and 100% schema coverage, so the description has no parameter burden to carry. The 0-parameter baseline of 4 applies.

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

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

The description identifies the domain (Storefront) and narrows the resource to 'guest profile', and the no-accounts note clarifies scope. However, it lacks an explicit verb such as 'returns' or 'retrieves', so an agent must infer the action from the tool name. It is vague rather than tautological, so 3 is appropriate.

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?

'Guest profile — no customer accounts' implies this tool is for guest, not account-specific preferences, and warns that no customer accounts exist. However, it never says when to prefer this over siblings or names alternatives, leaving usage mainly 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?

There are no annotations, so the description carries the full burden of disclosing behavior. It lists returned data categories but does not state that this is a read-only operation, whether authentication or merchant-of-record access is required, or how errors behave. 'Get' implies retrieval, but that is inferred, not disclosed.

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 entire description is one front-loaded sentence that packs the key output dimensions into a compact, readable form. There is no filler or redundant repetition.

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

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

For a single-parameter getter with no output schema and no annotations, the description names the main return categories, which is minimally viable. However, missing parameter guidance and behavioral context leave the definition thinner than it could be.

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%, and the description does not explain product_id or its expected format. It only implies that product_id identifies a product family, which adds some context but does not fully compensate for the missing parameter documentation.

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

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

The description clearly states the resource and scope: it returns details for one product family, including billing variants, price, access terms, and merchant of record. This distinguishes it from search, cart, and board siblings, 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 comparison to alternatives like search_products or get_cart. The use case is implied by 'Storefront' and 'product family' but never made explicit.

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

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

No annotations are provided, so the description must convey behavior. It mentions scoring and labeling but does not explicitly state that the tool is read-only or free of side effects. The lack of any indication of permissions or side effects leaves transparency insufficient.

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 overly verbose and includes irrelevant details such as 'Coil's own engine defers new entries' and 'pay-per-call'. It would benefit from a more focused and concise explanation.

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 explains the metrics and labels but does not specify the output format or structure. Given the lack of an output schema, this omission leaves the tool's return value unclear.

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

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

The tool has zero parameters, and the schema confirms this. The description does not need to explain parameters, but it also does not explicitly state that no input is required, leaving a minor gap.

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 it is a 'Sector and macro ROTATION map: where the money is going.' This conveys the core purpose, but the subsequent jargon about labels and metrics muddies it slightly.

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 includes confusing references to 'see `reading`', 'Coil's own engine', and 'Live sibling' without clear explanation. It does not effectively guide when to use this tool versus alternatives like get_rotation_live.

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

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

With no annotations, the description carries the transparency burden. It discloses cost ($0.005 USDC per call via x402), polling-friendly design, and the semantic caveat that confirmed rotation is late for pullback buyers. It does not mention response format or rate limits, but for a simple read-only polling tool this is reasonably transparent.

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

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

The description is three sentences with no filler: it leads with the core output, then adds a critical usage caveat, then provides the free alternative and cost. 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?

Given there is no output schema, the description conveys the core return semantics by listing the four states and referencing the `reading` field. It also includes cost, polling nature, and the delayed alternative. It does not detail the full response envelope, but for a zero-parameter polling tool it is largely complete.

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

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

The input schema has zero parameters and 100% schema coverage, so the baseline of 4 applies. There are no parameter semantics to clarify, and the description does not need to compensate for missing parameter documentation.

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

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

The description clearly states the tool's function: it returns live sector and macro X/SPY leadership states (GO / HOLDING / TURNING / OUT) recomputed intraday. It distinguishes itself from the sibling get_rotation by emphasizing 'Live' and contrasting with the 'one market day delayed' free version.

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 clear usage context: it is priced to be polled, and users without a wallet should use get_rotation instead. It also gives a behavioral caution about reading `reading` before acting because confirmed rotation is late for pullback buyers. It stops short of explicitly enumerating when not to use it, but the alternative is 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?

No annotations are provided, so the description correctly discloses key behavioral traits: one market day delay, unknown values return the sector directory, and the output includes member rankings and ETF row. It does not mention rate limits or auth, but for a read-only tool the delay and fallback are the most relevant traits.

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

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

The description is three sentences, each with distinct purpose: output content, input flexibility, and tier/alternative. There is no filler or redundant information.

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

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

With no output schema, the description provides a clear sense of the return value ('every member... scored and ranked... plus the sector's own ETF row'). It covers the tool's function, input format, fallback behavior, and alternative tool, making it complete for a one-parameter read 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 schema describes 'sector' as 'Sector name or sector-ETF symbol' (100% coverage), but the description adds concrete examples like 'Energy' and 'XLE', and explains the behavior for unknown values. This meaningfully extends the schema.

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

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

The description begins with 'One sector's drill-down' and specifies the exact outputs: every member scored and ranked by opportunity, plus the sector's own ETF row. This clearly distinguishes it from sibling tools like get_full_board or get_sector_read_live.

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 explicitly names the alternative 'get_sector_read_live' and labels it as pay-per-call, while stating the free tier has one market day delay. This tells the agent when to use this tool vs. the live sibling.

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

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

No annotations are provided, so the description must disclose behavior itself. It discloses the $0.01 USDC per call cost and the x402 payment protocol, plus the 'live intraday' nature and that it requires a wallet. It does not mention read-only status or rate limits, but 'read' in the name and the non-destructive description make side effects unlikely. This is a reasonable level of transparency for a paid data retrieval tool.

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

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

The description is three short sentences: purpose, alternative guidance, and pricing. Each sentence conveys distinct useful information with no filler, making it well-structured and easy to scan.

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 only one parameter and no output schema. The description explains what it does (scores and ranks sector members), when it's live, the cost, and the condition to use a free alternative. It lacks explicit details about the output format (e.g., an array of objects with score fields), but for a simple single-query tool this is arguably sufficient. A small gap in specifying exactly what 'scored and ranked' means keeps it just below a perfect score.

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

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

The single 'sector' parameter is fully described in the schema as 'Sector name or sector-ETF symbol.' The tool description only refers to 'a sector's members,' which is consistent but does not add extra syntax or examples beyond the schema. With 100% schema coverage, the description adds little marginal value, so a baseline score of 3 applies.

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

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

The description clearly identifies the tool as a live intraday version of get_sector_read, specifying that it scores and ranks a sector's members from the current session. It distinguishes itself from the delayed free alternative via the 'live' qualifier and explicitly names get_sector_read.

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 explicitly states that if the user has no wallet, they should use the free, one market day delayed get_sector_read instead. This provides clear conditional guidance for when to choose the alternative, and the 'live intraday' framing implies use when current session data is needed.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the data-delay behavior (free tier: one market day delayed), the fallback behavior for unknown symbols (returns valid-symbol directory), and the fact that every name carries coil fields. It could add rates/limits, but for a read tool this is strong coverage.

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

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

Four dense sentences with a clear front-loaded summary of what the tool returns. Every sentence adds information: output fields, accepted universe, unknown-symbol behavior, free tier caveat, and sibling routing. 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 single-parameter read tool with no output schema, this description is fully sufficient. The agent knows the input format, expected output content, error behavior, data freshness, and when to choose the live alternative. A higher score is not needed because the parameter count is minimal and the behavior is completely covered.

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

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

The schema documents only one parameter (symbol) with an example, so the description does not need to repeat syntax. It adds useful semantic context beyond the schema by telling the agent which symbol universe is accepted and what happens for unknown symbols.

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

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

The description states a specific verb+resource ('One stock's full Coil read') and enumerates the exact data fields delivered: opportunity 0-100, board percentile, entry quality/state, hold strength, leadership flag, and book regime. It also differentiates from the live sibling by naming get_stock_read_live explicitly.

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

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

The description gives clear scope ('Any S&P 500, Nasdaq-100 or macro name'), explains the free-tier delay, and routes to the paid live sibling when real-time data is required. It also tells the agent what happens for unknown symbols, which removes a likely error path.

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

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

With no annotations, the description carries the full burden and does well: it discloses that data is live intraday, that the call costs $0.005 USDC via x402, and that it includes specific coil fields. It implies wallet/payment requirements through the 'No wallet?' phrasing, though it could be more direct about a wallet being required and about any failure behavior without one.

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 core purpose, then delivery/alternative guidance, then the included coil read and pricing. Each sentence carries distinct information. A minor issue is the slightly awkward 'Live intraday get_stock_read' phrasing, but it does not waste 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?

For a single-parameter tool with no output schema, the description gives essential context: scope, price, and the alternative when no wallet is available. However, it does not clarify what 'entry state' means or describe the overall return structure beyond the coil fields, so an agent is left to infer the output 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?

The schema already documents the only parameter, symbol, with the example 'NVDA', so schema coverage is 100%. The description adds little beyond confirming the tool is for one stock; it does not add format details, validation rules, or market-hours context.

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 this as the live/intraday version of get_stock_read, scoped to one stock's current-session scores and entry state. It distinguishes itself from its main sibling by name and by explicitly including the live coil read, so an agent can tell it apart from the many other live variants.

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 provides explicit guidance: if the user has no wallet, use get_stock_read instead because it is free but one market day delayed. This contrasts real-time paid data with delayed free data and names the alternative, making the selection condition clear.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavior. It mentions session scope, which is useful, but does not state whether the operation is read-only, how results are returned, what happens when no memories exist, or how the optional skill_name parameter affects behavior.

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

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

The description is very short and the session-scope detail is front-loaded. However, the word 'Storefront' is a cryptic metaphor rather than a clear action, and the description is so minimal that it sacrifices useful information for brevity.

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 no annotations, no output schema, and one undocumented parameter, this description is incomplete. It fails to explain the meaning of skill_name, the output shape, or behavioral side effects, so an agent cannot reliably select and invoke the tool correctly.

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

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

The input schema describes skill_name only as a string with no description, and schema description coverage is 0%. The tool description never mentions skill_name or explains how it filters or scopes the recalled memories, leaving the agent without enough information to populate the parameter correctly.

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 identifies the resource as memories saved in the current session, which combined with the tool name 'recall_memories' clearly conveys a retrieval/listing operation. It is distinguishable from the sibling 'save_memory', though it does not 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?

No explicit guidance is given about when to use this tool versus alternatives. The session-scoped wording implies it is for accessing in-session memories, but there are no stated conditions, exclusions, or comparisons to sibling tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'remove a line' without revealing what happens to the cart, whether the operation is idempotent, what errors may occur, or what the effect is on other cart state. The mutation implication is clear, but beyond that the behavior is opaque.

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 short sentence with no wasted words. It is front-loaded and easy to skim. However, the brevity crosses into under-specification, omitting key context, which limits the structural value.

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 one parameter and no output schema, the description should at minimum define what 'line' means and how product_id is used. It does neither. The absence of annotations and schema descriptions leaves gaps in what the agent needs to call it correctly and predict outcomes.

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% and the description does not mention product_id at all. The parameter's role must be inferred entirely from its name and the tool name. The description adds no meaning about how product_id identifies the line to remove, any constraints, or behavior when the product is not in the cart.

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 'Storefront: remove a line' uses a clear action verb ('remove') and a resource ('line') that aligns with the tool's name 'remove_from_cart'. However, 'line' is somewhat vague jargon and the description does not explicitly connect it to a cart item, nor does it differentiate itself from siblings like update_cart_item beyond the verb.

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

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

The description gives no guidance on when to use this tool versus alternatives such as add_to_cart or update_cart_item. There is no mention of context, prerequisites, or situations that would favor remove_from_cart over other cart-related tools.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It communicates that the memory is ephemeral ('kept one day') and that 'save' performs a write. It does not disclose overwrite behavior, permission requirements, or what happens on retrieval, but the core lifecycle is minimally transparent.

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 sentence with no filler; the action, resource, and retention are immediately clear. The 'Storefront:' prefix adds a minor contextual label but does not hurt readability.

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 three undocumented parameters and no annotations, the description is underspecified. An agent does not know whether key/value are required, how duplicate keys behave, which categories are allowed, or how to later recall the saved memory. The one-day TTL is useful but insufficient for confident 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%, and the description adds no parameter-level meaning. 'key', 'value', and 'category' are self-descriptive at a basic level, but there is no guidance on requiredness, value formats, or how category affects storage. The schema lists zero required parameters, which the description fails to clarify.

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: 'save a session memory'. The retention period ('kept one day') adds useful distinction from permanent memory tools, and the save/recall contrast with the sibling recall_memories is implicit. It does not explicitly name the sibling, so it misses the top score.

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

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

The intended use is implied: store short-lived session memory with a one-day lifetime. It does not explicitly say when to use this tool versus alternatives, nor does it mention exclusions such as persistent storage. The context is enough to infer usage but not clearly prescribed.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only lists content categories and says nothing about side effects, read-only status, result behavior, or pagination. It does not contradict the name's implication of a search operation, but it adds no meaningful behavioral transparency beyond the category list.

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 and wastes no words; every listed item adds useful context. It is a fragment rather than a complete sentence, but its compact structure makes the domain scope immediately 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?

For a tool with no annotations and no output schema, the description is too skeletal to be a complete guide. An agent is left without an explicit statement of what the tool returns, how the query behaves, or what product_ids does. The category list is helpful but insufficient for confident 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 compensate for parameter meaning. It partially does by providing a vocabulary for the 'query' parameter (e.g., refunds, cancellation, delivery). However, it does not explain the optional 'product_ids' parameter or how it interacts with the search, leaving a significant gap.

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 resource domain as storefront policies, enumerating specific categories such as refunds, cancellation, delivery, and privacy. Although it lacks an explicit verb, the tool name 'search_policies' supplies the action, and the topic list distinguishes it from sibling tools like search_products.

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 list of policy topics provides implied usage context: an agent would know to use this tool when a user asks about refunds, cancellation, delivery, or similar storefront policies. However, there is no explicit guidance about when not to use it or how it compares to alternatives such as search_products.

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

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

With no annotations, the description carries the behavioral burden. It discloses what is returned (product families with a from-price) and what is deliberately omitted (billing variants). The search framing implies read-only behavior, though side effects and error cases are not mentioned.

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

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

Two sentences with no filler; the Storefront context and the product list are front-loaded. Every phrase adds useful information.

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 search tool, the description covers what it searches, what it returns, and where to find billing variants. The output shape and limit behavior could be more explicit, but an agent has enough context to select and invoke the tool correctly.

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

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

The description adds meaning to the required query parameter by framing it as a search over three named products. However, the optional limit parameter is undocumented in both the schema and the description, so its semantics are left to inference.

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

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

States a specific verb ('search'), a resource ('Coil's three products'), and explicitly lists the product names. It also distinguishes the tool from get_product_details by noting that billing variants come back there.

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?

Names get_product_details as the source for billing variants, giving a clear alternative for that specific case. It does not explicitly contrast with search_policies or say when not to use this tool, so it stops short of a perfect 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 no annotations provided, the description carries the full behavioral burden. It clearly discloses the non-obvious behaviors: a quantity of 0 removes the line and any quantity above 1 is clamped to 1. It does not mention auth, unknown product_id handling, or negative values, but the core mutation semantics are transparent.

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

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

One tight sentence that front-loads the domain and action and packs both meaningful gotchas into a parenthetical. Every word earns its place.

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

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

For a simple two-parameter mutation tool with no output schema, this is complete enough to select and invoke. It covers the action, domain, and important edge cases. It could additionally state what happens if the product is not in the cart, but that is not essential 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?

The schema has no descriptions (0% coverage), but the description adds crucial meaning for 'quantity' by explaining its edge-case behavior. 'product_id' is self-explanatory from the name, and the phrase 'a line's quantity' ties the parameter to the cart line being modified.

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

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

The description states a specific verb and resource: 'set a line's quantity' in the Storefront context. The quantity behavior (0 removes, above 1 held at 1) distinguishes it from add_to_cart and remove_from_art without needing to open 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?

The Storefront context and the verb 'set' clearly imply modifying an existing cart line, which separates it from add/remove siblings. It does not explicitly name alternatives or state when not to use it, so it stops just 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.