Coil Scanner

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds a real behavioral rule not in the annotations ('One licence per person, quantity 1'), which explains why the operation is idempotent and non-destructive, but says nothing about resulting cart state or failure behavior.

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

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

Two compact clauses, front-loaded with the Storefront context and the action. No filler, though 'billing variant' is slightly insider vocabulary that could be clearer without costing length.

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 tool with annotations and no output schema, the description covers purpose and the key business rule. It leaves gaps around the quantity parameter's expected range (schema says integer, description implies always 1) and does not mention auth or cart-state effects.

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

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

Schema coverage is 0%, so the description must compensate. It does add meaning: product_id is characterized as a 'billing variant' with an example ('coil-scanner-monthly') and quantity is effectively constrained to 1. It still omits format/type expectations for product_id, so compensation is partial rather than full.

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+resource ('add a billing variant' to the Storefront cart) and gives a concrete example value, so the agent knows exactly what the tool acts on. It does not explicitly contrast itself with remove_from_cart or update_cart_item, but the intent is unambiguous without that.

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

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

There is no explicit when-to-use guidance or routing to siblings such as update_cart_item (changing an existing line) or checkout_handoff. The only guidance is a business constraint ('One licence per person, quantity 1'), which is useful but not usage routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still earns credit by clarifying that this is a pure link-retrieval despite the 'checkout' name, that payment happens externally and 'nothing is charged by this tool,' and that Gumroad is merchant of record with promo codes applied only while a sale is live. It does not cover rate limits or link expiry.

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, front-loaded with the scope label 'Storefront:' and the core deliverable before the parenthetical detail. The parenthetical (Gumroad, merchant of record; promo code while a sale is live) is dense but each clause adds real context; nothing is redundant padding.

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 whose annotations carry the safety profile, the description supplies most of what an agent needs: it identifies the return artifact (checkout link per cart line) and disambiguates that no charge occurs here. Residual gaps are minor — whether multiple links are returned for multi-line carts is implied but not spelled out, and there is no note on link validity.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric. The description does not need to explain inputs, and it correctly avoids inventing any.

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 concrete deliverable — the hosted checkout link for each cart line — and names the payment processor (Gumroad) plus the merchant-of-record relationship. An agent can distinguish it from get_cart, add_to_cart, and get_orders because it is explicitly about the external payment link, not the cart contents or order state. It stops short of a crisp 'returns X' verb phrasing, and it never names a sibling directly.

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

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

Usage is implied rather than stated: the agent can infer this is called when a buyer is ready to pay, and the note that 'nothing is charged by this tool' rules out using it to take payment. However, no explicit when-to-use, prerequisites, or alternatives (e.g., get_cart, get_fulfillment_options) are named, so routing among cart-related siblings is left to inference.

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

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

Annotations cover the safety profile (readOnly, non-destructive, openWorld, non-idempotent), so the bar is lower, yet the description still adds real behavioral context: hash commitment, append-only/never-revised immutability, and the auth model (Coil Live subscription, 7-day trial, or x402 per-call wallet). It also discloses the failure mode — a PaymentRequired object and no data — which an agent needs before calling.

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

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

Purpose and immutability are front-loaded, then the index behavior, then auth/payment — a sensible order with little filler. The subscription/payment paragraph is dense, and the phrase 'this read returns live data' inside an archive tool is confusing rather than informative, costing a point.

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 carries the burden of explaining returns, and it does so for both special cases (archive index without `date`, PaymentRequired without entitlement). Auth and payment prerequisites are fully covered. It does not describe the shape of a successful score payload, but that gap is minor for a single-parameter read.

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 is one optional parameter and schema description coverage is 100%, so the schema already documents the YYYY-MM-DD format. The description adds the meaningful behavioral nuance that omitting `date` switches to an archive-index listing, but otherwise repeats what the schema states — baseline 3 for high coverage.

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

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

The first clause states a specific verb and resource with a distinctive scope: the point-in-time archive of scores published on an archived date, sha256-committed and append-only. That distinguishes it from the many live/board siblings without naming them. The later 'this read returns live data' line, dropped into a subscription discussion, muddies an otherwise crisp 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?

'Backtest-grade provenance' implies the when-to-use case (historical reproduction), and the date-omission behavior is spelled out. However, no sibling is named as an alternative (e.g. get_day_board or get_day_board_live) and there is no explicit when-not-to-use guidance, so routing is left partly to inference.

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

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

Annotations cover only the safety profile (readOnly, non-destructive, openWorld, non-idempotent); the description adds substantial behavior beyond them: the subscription/Coil Live connector requirement, x402 per-call payment, the PaymentRequired object returned when neither credential is present, and the fact that an unchanged `since` is answered free and never billed. This is exactly the credit-worthy context annotations cannot carry.

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

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

Front-loaded with the tool's meaning before the access model, and each sentence carries information. There is mild redundancy around the free-access cases ('free without since' and 'unchanged since is answered free'), which keeps it from being maximally tight.

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 complex, payment-gated diff tool with no output schema, the description covers the diff contents, both access modes, the required credentials, and the no-credential failure shape. An agent has everything needed to decide whether and how to call it, and the return payload is described in prose since no output schema exists.

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% and the single `since` parameter is fully documented there (including the 16-hex-char format and 'omit to receive the current state_hash'). The description largely restates that role, adding only the semantic tie to the previous-call provenance, 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 first sentence states a precise verb+resource ('what changed on the board since a state_hash') and enumerates the exact diff categories (READY pool entries/exits, trend-state/light/leadership/hold-band flips, regime/permission-ladder moves). It clearly differentiates a diff-tool from a snapshot tool, but never names the sibling it is distinct from (e.g. get_board_asof or get_day_board), so it falls short of full sibling differentiation.

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

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

It gives explicit when-to-use guidance for the two operating modes: pass `since` for a diff, omit it for the current state_hash only, and it discloses the access conditions for each path. It stops short of naming alternative tools to use for other board queries, so an agent knows how to use this tool but not explicitly when to prefer a 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds genuinely useful behavioral context: the data is a delayed free sample (one market day), the buy score is banded rather than numeric, and the list may not be actionable at all depending on regime mode. This goes meaningfully beyond the structured fields.

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

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

Front-loaded with the core purpose and dense but largely information-bearing, with the free-sample limitations placed last. It reads as a long run-on sentence, which slightly hurts scanability, but almost every clause adds distinct detail about the payload.

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 carries the return-value burden and does so well, enumerating picks per lane, top-3 READY candidates, buy band, entry window, ladder permission, regime mode, and READY count. The only gap is mild ambiguity around how the 'two lanes' relate to the crypto book mentioned parenthetically.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. Schema coverage is 100% and no input 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 names a specific resource (today's ranked buy-list) and details its scope precisely: two lanes, per-book picks, READY candidates, buy bands, entry windows, and regime mode. It implicitly distinguishes itself from get_buy_list_live via the 'free sample / one market day delayed' framing, but never names the sibling 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 explains what the tool returns but says nothing about when to use it versus alternatives. The 'free sample' and 'one market day delayed' clues hint at a premium/live counterpart, but the agent is left to infer this and no alternative tool 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?

Goes well beyond annotations: it discloses the auth model (subscription + sign-in), a pay-per-call fallback via x402, and the exact failure behavior (a PaymentRequired object and no data). These are behavioral traits the readOnly/openWorld/idempotent hints cannot convey.

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

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

Front-loads what the tool returns and then covers access mechanics in three tight sentences. Slight redundancy between "Live intraday" in the first sentence and the standalone "Live intraday version" sentence, but nothing meaningfully 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?

With no parameters and no output schema, the description carries the load and does so adequately: it names the candidate scope, the entry states, and the failure object. It stops short of describing the shape of a successful payload, which is the only remaining gap.

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

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

There are zero parameters and 100% schema coverage, so the baseline is 4. The description correctly adds behavior-like qualifiers (READY/SETTING UP entry windows, asset-class scope) rather than re-documenting nonexistent parameters.

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+resource: live intraday ranked buy-list candidates across US stocks and ETFs (with the crypto book noted). The phrase "Live intraday version" cleanly separates it from the non-live sibling get_buy_list without needing 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?

Clearly states the conditions under which it returns data (Coil Live subscription + connector sign-in, or an x402 wallet) and the condition under which it yields nothing. It does not explicitly route to the non-live get_buy_list for as-of/historical reads, so alternative guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to cover safety. It adds useful session-header context (X-Session-Id / Mcp-Session-Id), which is not present in annotations, but does not explain what happens if session is missing or what the return looks like.

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

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

Extremely concise one-liner with no wasted words. It is front-loaded with the resource, though it reads as a fragment rather than a structured sentence, and could be slightly more explicit about the retrieval action.

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

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

Given the tool is a zero-parameter read with full annotation coverage, the description provides the essential session-header hint. However, it lacks usage guidance and return-value context (no output schema exists), leaving minor gaps for an agent unfamiliar with cart semantics.

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

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

There are zero parameters, so the baseline is 4. The description correctly notes that session identity comes via headers, which is relevant context even though no parameters exist.

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 is a noun phrase that identifies the resource (the session's cart) but does not state a verb or action. The tool name 'get_cart' supplies the verb, but the description itself is somewhat vague about what the tool does. It distinguishes from write siblings like add_to_cart only via the resource name, not explicit wording.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention add_to_cart, remove_from_cart, update_cart_item, or any condition for selecting this read operation. Usage is only implied by the name.

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

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

Annotations already declare readOnly, idempotent, non-openWorld, so the safety profile is covered. The description adds real context beyond that: 24/7 availability, that it is a trimmed slice of a fuller state map, what fields exist per coin (trend distance, tape lights, ATR%, RS vs BTC, room, volume z-score, UP/CHOP/DOWN), and freshness claims vs a delayed copy.

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

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

Front-loaded with the core content (top-3 of 81, BTC anchor, gate regime, breadth) in the first sentence, then the state-map contents. Slightly dense, and the paired negatives ('not a delayed copy', 'not a ranking or advice') lean toward redundancy, but nothing is 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?

With no parameters, no output schema and safety covered by annotations, the description carries the remaining burden and does so well by enumerating the returned fields and scope. The one gap is the absence of an explicit freshness/refresh contract 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?

Zero parameters, so there is no parameter semantics to document and the baseline is 4. The description correctly implies a no-argument call by describing a fixed, always-on board rather than a queryable one.

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

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

Specific verb+resource: a 24/7 crypto day-state snapshot limited to the top-3 of 81 Robinhood-tradable coins plus BTC anchor, BTC/ETH gate regime and breadth counts. It clearly says what the tool returns and even what it is not ('a state map, not a ranking or advice'), but it never names the sibling get_crypto_day_live, leaving the preview-vs-live distinction implicit.

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 'PREVIEW' framing and 'a live trimmed slice ... not a delayed copy' imply it's a lightweight snapshot, and 'Free' hints at a cost tradeoff versus heavier siblings. However it never states when to pick this over get_crypto_day_live, get_crypto_night or get_full_board, so routing is left to inference.

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

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower, yet the description adds substantive behavior: a ~5-minute publishing cadence, the PaymentRequired failure mode and both access paths (subscription or x402 wallet), and the fact it returns no data without one. It does not mention pagination or the exact shape of the returned board, which keeps it out of 5 territory.

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 payload is dense but front-loaded: the top-level resource and field list come first, followed by cadence, the state-map-vs-ranking caveat, and access terms. Most sentences carry distinct information, though the enumeration runs long and the access/payment sentences could be tightened.

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

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

With no output schema and no parameters, the description must carry the return-content and access burden, and it does so thoroughly: it lists the metrics returned and explains the authentication/payment gate and its failure mode. Only the concrete shape of the returned object and any rate/refresh nuances are left unstated, which is minor 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 takes zero parameters (schema coverage 100%, empty object with additionalProperties false), so per the rubric the baseline is 4. There is nothing for the description to clarify about inputs.

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 specific resource (24/7 crypto day-state board) and enumerates the exact fields returned (trend distances, tape lights, ATR%, relative strength, state, ranks), so an agent knows precisely what it gets. It distinguishes itself as the 'Live intraday version' but never names get_crypto_day as the non-live counterpart, leaving sibling differentiation to inference.

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

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

Usage is implied and partially gated: 'subscribers connect the Coil Live connector and sign in', or pay per call via x402, otherwise a PaymentRequired object is returned. That is useful access context, but there is no explicit when-to-use-this vs get_crypto_day, get_crypto_night_live, or get_crypto_setups_live, and 'a state map, not a ranking' only hints at the boundary versus ranking siblings.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description still adds real context: it is free, it is a state read not advice, and it honestly discloses that the studied trade was REFUTED at Robinhood retail fees. It omits return format and pagination, but the disclosure of the refutation is genuinely useful behavioral information.

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 resource and scope, and each sentence carries information (what it returns, the study validation, the honest refutation caveat, and the free/not-advice tags). It is dense and somewhat promotional in tone, but there is little outright 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?

With no output schema and no parameters, the description carries the burden of explaining what comes back, and it does so reasonably well (the ranked coin, BTC 200-day gate, phase, study receipts). It stops short of describing the shape of the returned payload, but for a parameterless read tool it is fairly 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 takes zero parameters, so there is no parameter semantics to document; the baseline for a no-parameter tool is 4. Nothing in the description misrepresents the (empty) input contract.

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

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

The description states a clear resource and scope: the top session-momentum coin heading into the 20:00 UTC signal, plus BTC regime gate, phase, and study receipts. It is highly specific about what is returned, but it never names or differentiates from the obvious sibling get_crypto_night_live, leaving the preview-vs-live distinction to inference.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives such as get_crypto_night_live. The reader can infer that a 'PREVIEW' is the non-live counterpart, but the description never states the condition that selects this tool over its 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?

Annotations cover safety (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), but the description adds substantial operational context they cannot: ~15-min refresh cadence, 24/7 operation, and the full auth model (subscription with 7-day trial, connector sign-in, x402 pay-per-call). Critically, it discloses the failure mode: without subscription or x402 wallet it returns a PaymentRequired object and no data.

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

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

Front-loaded with the content inventory and then the access model, so the agent gets the essential picture on the first read. It is dense and relies on somewhat opaque jargon ('session-momentum coins,' 'registered rule + study receipts'), but nearly every clause carries distinct 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 and no parameters, the description carries the burden and does so well: it describes the payload contents, the refresh cadence, and the payment/auth gating including the PaymentRequired fallback. It stops short of explicitly naming the non-live sibling for disambiguation, which is the only meaningful gap.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter detail because none exist, and the empty schema is self-explanatory.

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

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

Names a specific resource and enumerates its exact contents: top-5 session-momentum coins into the 20:00 UTC signal, BTC 200-day regime gate state, phase clock, eligibility counts, and rule/study receipts. It also self-identifies as the 'Live intraday version,' which implicitly separates it from the non-live get_crypto_night sibling, but it never names that alternative outright.

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

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

Usage is only implied: calling this for live data versus the non-live night read is left to inference from the phrase 'Live intraday version.' There is no explicit when-to-use or when-not-to-use against get_crypto_night, get_crypto_day_live, or the other crypto reads. Adequate but with a clear routing gap.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the return content (count plus top-3 hits by grade with GO, fuel vs BTC and room), labels the data as backtest-confirmed on equities and forward-graded on crypto, and explicitly frames it as 'a descriptive marker, not advice.'

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 tight sentences, front-loaded with the scan scope before the return payload and the caveats. Nothing redundant, and the 'not advice'/'Free' trailers are short and purposeful.

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

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

With no output schema and no input parameters, the description carries the burden of describing the response and does so ('how many... plus the top-3 hits by grade with GO, fuel vs BTC and room'). It stops short of explaining what GO/fuel/room measure or data freshness, which leaves minor gaps for an agent interpreting the 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?

The tool takes no parameters and the schema is empty, so there is nothing for the description to document. A 4 baseline is appropriate.

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

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

States a specific verb and resource ('Crypto SETUP scan PREVIEW') and quantifies the scope (81 Robinhood-tradable coins, two washed-shape SETUP patterns). 'A live trimmed slice of the full scan' implicitly separates it from the fuller scan siblings, though it never names get_crypto_setups_live, so differentiation is inferential rather than explicit.

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 word 'PREVIEW' and 'trimmed slice of the full scan' imply when this is the lighter-weight option, but there is no explicit when-to-use, when-not, or named alternative. An agent must infer the routing from the sibling names.

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

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

Goes well beyond the readOnly/openWorld annotations by disclosing refresh cadence (~every 5 minutes, 24/7), the auth/subscription requirement, the x402 pay-per-call path, and the explicit failure mode (PaymentRequired with no data). It also discloses the backtest/forward-grade provenance of the setup shapes.

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

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

Front-loads the scan scope and return contents, then cadence and payment terms. Mostly efficient, but there is mild redundancy ('Live intraday version' restates the already-implied live framing) and heavy capitalized emphasis that adds bulk without adding 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 zero-parameter tool with no output schema, the description supplies the return fields (GO, fuel multiple vs BTC, grade, room, setup column), the refresh cadence, and the payment gating failure mode. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes no parameters, so there is nothing for the description to add; the baseline for a zero-parameter tool applies. No parameter meaning is missing because none exist.

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 — scanning all 81 Robinhood-tradable coins for defined washed-setup shapes — and explicitly frames itself as the 'Live intraday version,' distinguishing it from the non-live get_crypto_setups sibling. An agent knows exactly what this returns without opening the schema.

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

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

Prerequisites and context are clear: it is the live/intraday read, requires a Coil Live subscription (or x402 pay-per-call), and otherwise returns a PaymentRequired object. However, it never names the alternative (get_crypto_setups) or states when to prefer cached vs live, leaving the sibling choice implicit.

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

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

Annotations already declare readOnly/idempotent/closed-world, yet the description adds substantial non-obvious behavior: it is free, runs exactly one completed UTC close behind, updates every calendar day including weekends, and stamps output with signal_close_date. This staleness and cadence disclosure is exactly the kind of trait an agent cannot infer from 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?

Front-loaded with the resource and its outputs before the risk-on/risk-off framing and operational caveats. Dense but every clause carries substantive meaning; the parenthetical enumerations are informative rather than 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?

With no output schema, the description carries the full burden of explaining returns and does so completely: it names each signal, the gate hierarchy, the overriding master gate, and the timestamp field. An agent has enough to interpret the response without additional documentation.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter syntax to clarify. The description instead spends its words defining the returned fields (LONG/CASH states, gates, price and day change), which is beyond any schema burden here.

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

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

States a specific resource (BTC/ETH trend signal) and enumerates the exact outputs: long-only state per sleeve, 50-day trend gate, and the BTC 200-day master gate. It explicitly frames itself as a rules-based verdict rather than raw price data. It does not explicitly differentiate from the sibling get_crypto_trend_live, though 'exactly one completed UTC close behind' implicitly contrasts the lagged vs 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?

The description positions the tool as 'a rules-based risk-on/risk-off verdict, not raw price data,' which implies the correct use case versus price-data siblings. However, it never names get_crypto_trend_live or states when to prefer the lagged version over the live one, leaving the alternative selection to inference.

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

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

Annotations already declare readOnly, openWorld, non-idempotent, non-destructive. The description adds real value beyond that: the payment/auth requirement, the exact failure mode (PaymentRequired object), the evaluation cadence (every calendar day incl. weekends), and the stamped close used. This is meaningful 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?

Front-loaded with what the signal is and how it is computed, then the access/payment terms. Dense but each clause carries information; slightly long but no filler sentences.

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

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

With no output schema, the description carries the return-value burden and does reasonably well, naming the output values (LONG or CASH per sleeve) and the error case. An agent has enough to call it and interpret the result, though exact response shape is only sketched.

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?

Zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies no input is required.

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

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

States a specific verb+resource (crypto trend signal) and enumerates the mechanics (LONG/CASH per sleeve, 50-day gates, BTC 200-day master gate). It also signals the differentiator from the free tier ('one close ahead of the free tier'), though it never names get_crypto_trend as the alternative, so differentiation is implied rather than explicit.

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

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

Clearly states the access conditions: a Coil Live subscription or an x402 wallet, and the consequence (PaymentRequired object, no data) otherwise. It does not, however, tell the agent when to choose this over the free get_crypto_trend sibling beyond the implicit 'one close ahead' hint.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context beyond them: a one-market-day data lag, the fact that day states decay in minutes making the data stale by design, and a hard sample cap of 3 names plus 2 per cohort. These are exactly the traits an agent needs to avoid misusing the output.

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-loaded with what the board contains and then the delay/sample caveats; every sentence carries information. It is dense with domain jargon (GO, FUEL, ROOM, lights grid) that is not unpacked, which slightly hurts immediate comprehension even though the payload reportedly includes a reading guide.

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 must convey the return shape, and it does: it lists the grid axes and per-name/cohort fields and states the sample size. It does not describe machine-readable structure or ordering, so an agent still has residual uncertainty about the exact response format, but the substantive content is covered.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a no-parameter tool is 4. The description correctly introduces no parameter syntax that would conflict with 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 names the resource (day-trade state map) and enumerates its concrete contents: per-name intraday lights grid across price/RSI/MACD timeframes, GO, FUEL vs anchor ETF, entry-window state and ROOM, cohort anchors, reading guide. It distinguishes itself from the closest sibling by explicitly framing itself as the 'delayed tier' versus a live feed, so an agent can separate it from get_day_board_live without opening either schema.

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

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

It gives clear when-not-to-use guidance ('not a trading input', 'day states decay in minutes', delayed by one market day) and implies the correct use case: schema/shape preview. It stops short of naming the live alternative (get_day_board_live) explicitly, so routing is inferred rather than spelled out.

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

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

Annotations cover safety (readOnly, non-destructive, openWorld), and the description adds substantial value beyond them: the ~5 min in-market refresh cadence, the meaning of the ext:true late flag, and the full auth model (Coil Live subscription with 7-day trial, connector sign-in, or x402 pay-per-call). It explicitly discloses failure behavior: without subscription or wallet it returns a PaymentRequired object and no data.

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

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

Front-loaded with the resource and its contents, then the caveats (state map not ranking, auth/payment). It is dense and jargon-heavy, but nearly every clause (refresh rate, ext flag, payment fallback) carries operational meaning, so little 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?

Given 0 params and no output schema, the description compensates by naming the fields surfaced on the board and the refresh behavior, and it warns of the PaymentRequired fallback. It stops short of describing the shape of the returned object, but for a read-only board tool with no schema this is close to 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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly implies a no-argument read and adds no misleading parameter claims.

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

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

States a specific verb and resource (get the live day-trade board) and enumerates exactly what the board contains: 18-cell lights grid, GO, FUEL vs anchor ETF, efficiency, ATR%, vs-SPY, entry-window, ROOM on ~70 names. It also draws a clear conceptual boundary ('A STATE MAP, not a ranking') and identifies itself as the 'Live intraday version', which distinguishes it from the non-live get_day_board sibling.

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

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

The 'Live intraday version' framing plus the ~5 min refresh window tells the agent when this is appropriate versus a static/as-of board. However, it never explicitly names an alternative (e.g., get_day_board or get_board_asof) or states a when-not condition, so routing is implied rather than spelled out.

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

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

Annotations already cover the safety profile (readOnly, idempotent, destructive false), and the description goes well beyond them: concrete payload sizes for filtered/compact/unfiltered reads, ~5-minute refresh in market hours, identical-for-all-subscribers semantics, auth/subscription requirements, and the compact=true effect on the embedded schema block.

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

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

Front-loads the identity ('THE COIL LIVE FEED') and keeps the operational facts (size, cadence, auth, paging) in one dense block. It is long and slightly repetitive about the schema block and compact behavior, but nearly every sentence carries actionable detail.

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 carries the return-shape burden and does so: it names the engine_fields, the self-describing payload `schema` block (key · tier · description · since), the blocks dropped under compact, and what always rides along. Auth, cadence, and sizing are all present, leaving no material gap for correct invocation.

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

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

Schema coverage is 100%, so the schema already defines each parameter; the description adds consequence-level meaning the schema lacks, e.g. ~1.35 MB unfiltered vs ~70 KB for two symbols vs ~12 KB with compact=true, and that fields[] selects engine field keys while compact=true uses the core 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?

States a specific resource (the Coil live engine-grade board) and explicitly positions it as 'a superset of the complete live board that adds per-name structural stop and target levels, ... buy_score, conviction, lane, leveraged vehicle and ladder placement'. That superset framing lets an agent distinguish it from siblings like get_full_board or get_day_board_live without opening schemas.

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

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

Gives clear context: it is the engine-grade board, and it documents the subscription prerequisite (subscribers connect the Coil Live connector and sign in) plus refresh cadence. However it never names a sibling alternative or an explicit when-not condition, so the routing guidance is implicit rather than spelled out.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds only a marketing-style attribute of digital delivery ('instant, no fee') and does not disclose what the tool returns, whether options are per-product, or any limitations.

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 phrase is short and front-loaded, but it is under-specified rather than concise; it omits the action and parameter. A concise definition still needs to say what the tool does.

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

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

For a simple read tool, the annotations cover safety, but the description omits the required product_ids relationship and any return context. It is not complete enough for an agent to call correctly without opening the schema.

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

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

The schema has one required parameter, product_ids, with 0% description coverage, and the description never mentions the parameter or its expected format. The agent gets no help on what to pass.

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 a verb or resource; it reads as a product attribute label rather than a tool action. An agent cannot tell that it returns fulfillment options for the provided product_ids, and it is not differentiated from storefront siblings like get_product_details or get_cart.

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

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

No when-to-use, when-not-to-use, or alternative is provided. The fragment gives no signal about how this tool relates to add_to_cart, checkout_handoff, or get_product_details.

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?

Goes well beyond the annotations: it discloses the access model (7-day free trial subscription, x402 pay-per-call wallet) and the failure mode (returns a PaymentRequired object with no data without one), plus the self-described `schema` block and awareness block structure. This is exactly the behavioral context annotations cannot carry.

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

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

Front-loaded with the resource and payload contents, followed by field structure and then the payment/access caveats. Dense but every clause carries information; minor redundancy in restating payload contents twice.

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 takes on the burden of explaining returns, and it does so (coil fields, awareness block, self-describing schema block) while also covering the payment-required failure path. An agent has enough to invoke and interpret it.

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

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

The tool takes no parameters, so the baseline is 4. The description correctly implies a no-argument, single-shot read rather than inventing parameter semantics that do not exist.

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 ('complete live board in one payload') and enumerates exactly what it contains (scored names, sector lanes, buy-list lanes, regime/crypto books). This implicitly distinguishes it from the granular siblings (get_buy_list, get_crypto_day, get_market_regime), though it never names an alternative outright.

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

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

Usage is implied by 'complete ... in one payload' and 'Live intraday version', which hints at when to use this aggregate vs. the per-slice siblings and vs. the as-of variant. However, no explicit when-to-use or when-not-to-use statement, and no sibling 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?

Beyond the readOnly/idempotent annotations, it discloses substantive operational traits: sample limits (3 symbols, headline fields only), a one-market-day data delay, and that it never reads entry, size or account. It also pins the exact conditions behind watch_flags and that mechanical flip rules are returned.

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

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

Front-loaded with the framing question that tells the agent what the tool is for, and every clause carries information (return fields, watch_flags enumeration, sample limits). It is a single long run-on paragraph with heavy parentheticals, which costs it a point on structure but not on substance.

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?

There is no output schema, so the description carries the return-value burden and does so thoroughly: it lists each returned field and spells out the seven watch_flag conditions. Combined with delay, sample caps and crypto handling, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100% with a single documented 'symbol' param, so baseline is 3. The description earns extra credit by adding crypto-specific semantics not in the schema: BTC-USD/ETH-USD return the crypto IN|CASH daily-close state, and comma-separated multi-symbol input is bounded at 3.

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

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

States a specific verb+resource ('sell-side read' of hold state for a name you already hold) and enumerates the exact return payload (trend state, hold label, maturity-late flag, gap-risk level, regime, watch_flags). It distinguishes itself from buy-side siblings and, via the 'one market day delayed' free sample, from the live variant.

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?

Frames the decision it supports ('is the case for a name you already hold still intact, or deteriorating?') and scopes itself to held positions, which selects it over get_buy_list and get_stock_read. It never explicitly names get_hold_state_live as the alternative or states exclusions, so no full 5.

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

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

Annotations cover the safety profile (readOnly, non-destructive, open-world), and the description adds genuinely non-obvious behavior: a 10-symbol cap, that it reports conditions only and never reads entry or size, and that unauthenticated calls return a PaymentRequired object rather than data. The idempotentHint=false is not explained, but the added behavioral context is substantial.

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

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

Front-loads the core purpose, then qualifies scope and access. The output enumeration is dense but each item is informative, and there is little wasted text. Slightly list-heavy for a four-sentence description.

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

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

With no output schema, the description usefully enumerates the returned condition fields and explains the payment-gated failure mode, which an agent needs to interpret an empty response. Rate limits and pagination are not addressed, but the tool is a single capped read.

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% and the single symbol parameter is fully documented there, so the baseline is 3. The description's 'up to 10 symbols per call' reinforces the batch limit but adds no new syntax beyond the schema.

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

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

States a specific verb (read), resource (hold state), and scope (live intraday SELL-SIDE, names you already hold), then enumerates the exact outputs. It is clearly distinguishable from the non-live sibling get_hold_state and from buy-side reads like get_buy_list_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?

Explains the access conditions an agent must know before calling: a Coil Live subscription (7-day trial), an x402 wallet for pay-per-call, or a PaymentRequired response with no data. It does not explicitly state when to prefer the non-live get_hold_state over this one, so routing between the two is left implicit.

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

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

Annotations already cover read-only/idempotent/no-destructive, so the bar is lower; the description adds versioning behavior and the fact that the payload itself signals when rules changed, plus the subscription/sign-in requirement. It does not describe payload size or caching/staleness characteristics.

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

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

Front-loaded with the resource and its content, followed by a compact second sentence covering versioning and access. The phrase 'engine-grade feed' and the run-on list are mildly wasteful but the text is short overall.

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 usefully enumerates what the rulebook contains and notes that change timing is embedded in the payload, which is enough for a zero-param read tool. Only the shape/format of the returned document remains unspecified.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate.

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

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

States a specific resource ('the Coil Live served rulebook') with a clear get semantic implied by the name, and enumerates the payload's subject matter (cycle order, exits-first, stop derivation, day-lane rhythm, sizing, fail-closed rules). It does not, however, distinguish itself from adjacent read tools such as get_engine_feed.

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?

Adds a real prerequisite: the caller must be a Coil Live subscriber with the connector connected and signed in, and the read only returns live data. But it names no alternative tool and gives no when-not condition, so the selection guidance is only implied.

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

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

Beyond the annotations, the description discloses meaningful behavior: what the subscription unlocks, how the license key is sent, the recommended polling cadence, and fail-closed behavior if the subscription lapses. These details materially help an agent understand the tool's operational 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 front-loaded and every clause adds useful information, but it is packed into a single dense sentence that could be easier to scan. It avoids outright waste.

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 setup tool, the description covers the relevant access terms, subscription behavior, key handling, polling guidance, and failure mode. Nothing critical for correct invocation appears to be 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?

There are no input parameters to document, so the baseline is 4. The statement 'Free; no key needed' clarifies that no authentication parameter is expected, though the empty schema already makes that clear.

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 that the tool returns Coil Live connection details and enumerates the relevant content: entitlement scope, license-key transport, polling cadence, and fail-closed behavior. However, it does not explicitly differentiate this setup tool from sibling live-data tools such as get_engine_feed or get_live_rules.

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 limited routing context by stating the tool is free and requires no license key, and by describing what a Live subscription unlocks. It does not explicitly say when to call this tool instead of the many live-tier sibling tools, or whether it should be used before them.

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

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

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the bar is lower. The description adds genuine behavioral context beyond that: the result is limited to the top 3 per book, headline fields only, and delayed by one market day. These freshness/scope constraints are the key non-obvious traits and are 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?

Leads with the resource and ranking, then fields, then the awareness block, then the sample/delay caveat. Dense but front-loaded and mostly waste-free, though the parenthetical explanations add minor verbosity.

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?

There is no output schema, so the description must carry the return-value burden, and it does – enumerating price, day change, opportunity percentile band, entry state, and the awareness block (sector money flows, coverage, coiled-setup count). Coverage is strong, with only the exact response shape and pagination left unspecified.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain and the baseline is 4. The description adds no misleading parameter detail.

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

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

Specific verb (get) and resource (market leaders) with a rich description of scope: top 3 per book across US stocks, ETFs and crypto, ranked by opportunity score, with named fields. It distinguishes itself from most siblings by content, but the obvious live counterpart get_market_leaders_live is only implicitly distinguished via 'one market day delayed' rather than named directly.

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 'Free sample... one market day delayed' clause implies this is the delayed/sample variant and hints at when to use it, but there is no explicit when-to-use guidance or named alternative (get_market_leaders_live). Usage is left for the agent to infer from the delay note.

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?

Goes well beyond the readOnly/openWorld annotations by disclosing the full access/payment model: subscription path, x402 pay-per-call path, and the exact failure mode (returns a PaymentRequired object with no data when neither is available). This is the kind of behavioral context an agent needs before invoking.

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

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

Front-loaded with the purpose and return contents, then the access/payment behavior, which is the right ordering. Slightly redundant, as 'recomputed on the intraday board' and 'Live intraday version' restate the same idea, but nothing is wasted overall.

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 compensates by describing what comes back (top 10 per book, live awareness block with sector money flows, coil setups with coil_score, coverage) and fully covers the auth/payment prerequisites and error behavior. Nothing needed to call it correctly is missing.

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

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

Zero parameters, so there is nothing to document and the schema is trivially complete. The baseline for a no-parameter tool is 4; the description correctly adds no spurious parameter detail.

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

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

States a specific verb+resource: top 10 leadership names per book (US stocks, ETFs, crypto coins) ranked by opportunity score and recomputed on the intraday board. The 'live' scope plus the named output contents (sector money flows, coiled setups with coil_score, coverage) clearly distinguish it from the non-live sibling get_market_leaders.

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 frames itself as the 'Live intraday version' and lays out the conditions to get data: a Coil Live subscription (7-day trial), connecting the connector and signing in, or an x402 wallet for per-call payment. It doesn't explicitly name get_market_leaders as the non-live alternative, but the live-vs-static distinction is clear from context.

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

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

Annotations already cover read-only/open-world/non-idempotent, and the description adds real value: the ~5-minute recompute during market hours (which justifies idempotentHint=false), the subscription-plus-sign-in requirement, the x402 per-call payment path, and the failure mode (PaymentRequired object with no data). Returned field semantics are not described, holding it below 5.

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

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

Front-loads what the tool returns and its cadence, then handles the commercial/access model in tightly packed clauses. The final sentence about PaymentRequired is essential, but the 'Live intraday version.' fragment is slightly redundant with the opening sentence.

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

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

With no parameters and no output schema, the agent needs the access model and the failure behavior most, and both are supplied. The remaining gap is that the named payload elements (verdict, mode, permission ladder) are never explained, so an agent knows what it gets only by name.

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?

Zero parameters with 100% schema coverage, so the schema baseline of 4 applies; there is nothing for the description to clarify and it does not need to.

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

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

States a concrete resource (live intraday stock market regime, including the crypto book) and enumerates the payload conceptually (verdict, mode, permission ladder) with a refresh cadence. The 'Live intraday version' line plus the sibling get_market_regime makes the live-vs-historical split unambiguous.

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

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

Explicitly states the access conditions: subscribe to Coil Live and sign in via the connector, or pay per call with an x402 wallet. It does not explicitly route agents to the non-live get_market_regime sibling for historical data, leaving that inference to the name, which keeps it short of a 5.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds real behavioral context beyond them: it is a free sample capped at top 3 per list with headline fields only, and it is delayed by one market day. That sets expectations about freshness and completeness that the annotations do not.

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 content is front-loaded ('The stock market read in one payload') and information-dense, with the sample limitation placed last. It is a long run-on first sentence but nearly every clause enumerates a distinct returned section, so it earns its length.

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?

There is no output schema and no parameters, so the description bears the burden of describing the return contents, which it does thoroughly by naming each section of the brief. The only gap is the lack of routing to the live counterpart.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. No schema-level meaning is left unexplained.

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 enumerates the concrete payload contents (regime verdict per book, top 3 buy candidates, gainers/losers, BTC/ETH trend-gate, awareness sample), which clearly conveys the resource. However, it never names the sibling get_morning_brief_live, so an agent must infer the distinction between this and the live variant from the 'free sample' phrasing alone.

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 'Free sample' and 'one market day delayed' notes hint that a fuller/real-time alternative exists, but the description gives no explicit when-to-use guidance and does not name the live sibling as the alternative. Selection between this and get_morning_brief_live is left entirely to inference.

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

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

Annotations already declare readOnly, openWorld, idempotent=false, destructive=false, but the description adds critical context beyond them: the payment/auth model (subscription or x402 wallet) and the exact failure behavior (returns a PaymentRequired object with no data when neither is present). That failure-mode disclosure is exactly the kind of trait an agent needs before calling.

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?

It is front-loaded with what the payload contains before pivoting to access requirements, which is the right ordering. The subscription sentence is slightly wordy ('connect the Coil Live connector and sign in') but every sentence carries information an agent needs.

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 must convey returns, and it does list the included sections (regime, candidates, movers, crypto gate, awareness read with leaders, money flows, coiled setups, coverage) plus the error shape. Enough to call correctly, though it doesn't describe payload shape or freshness/latency details.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter guidance because there is nothing to configure.

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 specific verb (get) and enumerates the payload contents (regime, top-5 candidates, movers, crypto gate, awareness read), and labels it the 'Live intraday version,' which separates it from the non-live sibling get_morning_brief. Differentiation is implied rather than explicitly naming the sibling, so it falls short of a 5.

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

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

It gives clear access prerequisites: a Coil Live subscription (7-day trial) with connector sign-in, or an x402 wallet for per-call payment. It stops short of explicitly routing agents to get_morning_brief when they want end-of-day rather than live data, so the alternative-selection guidance is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine value by disclosing the return payload's breadth (all billing variants, prices, access terms, merchant of record), but says nothing about pagination, availability, or error behavior.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the terseness comes at the cost of the usage and parameter context an agent would want.

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?

There is no output schema, so the description must carry return-value meaning, and it does list the response contents. However, it omits the required product_id input entirely and gives no guidance on how to obtain one, leaving a real gap for a tool this simple to call correctly.

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

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

Schema coverage is 0% and the single required parameter product_id is never mentioned or explained. 'One product family' faintly implies the input identifies a family, but nothing says what form the ID takes or that it is mandatory, so the description does not compensate for the coverage 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 names a specific resource and enumerates what the payload contains (product family, billing variants, price, access terms, merchant of record), so the agent knows this is the detail-fetch counterpart to search_products. It never uses an explicit verb like 'retrieve' and does not name the sibling, but the scope is unambiguous.

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

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

There is no when-to-use statement, no pointer to search_products as the way to discover a product_id, and no mention of prerequisites. The agent must infer this tool's role purely from the noun phrase about its contents.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real value: the scoring method (ratio to SPY vs 50-day), the four state labels, the payload structure, and the free-sample truncation (5 rows, first 3 ETFs per state, one-day delay).

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

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

The purpose is front-loaded in the first clause and nothing is padding. However, the second sentence is a single very dense run-on packing scoring, labels, and row layout, which hurts scannability.

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 must carry the return-value burden, and it does: it enumerates the instrument universe (~50 ETFs plus macro-book instruments), the state lists, the row fields (symbol, kind, label, state), and the free-sample limits. Nothing needed to interpret the response is missing.

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

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

The tool takes no parameters, so the schema carries no semantics to explain; baseline 4 applies. The description correctly spends no words on inputs.

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

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

States a specific resource ('Sector and macro ROTATION map') and what it contains, going well beyond a restatement of the name. It implicitly differentiates from get_rotation_live via the 'free sample... one market day delayed' note, but never names that sibling, so the differentiation is left to inference.

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

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

It clarifies interpretation ('A state map, not a buy list') and flags that confirmed rotation is late for a pullback buyer, which is useful framing. However, it gives no explicit when-to-use routing versus get_rotation_live, so the agent must infer that this is the delayed/sample tier rather than the live one.

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

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

Beyond the annotations, it discloses auth and payment requirements: Coil Live subscription (7-day trial), connector sign-in, and x402 per-call payment. It also states the failure mode—without a subscription or x402 wallet, it returns a PaymentRequired object and no data—and notes the payload's `reading` field, adding rich behavioral context for invocation.

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 return content and then adds prerequisites and failure behavior. The sentence about the payload's `reading` field is somewhat cryptic and could be trimmed, but overall the length is justified by the auth and payment details.

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 carries the burden of explaining what is returned. It states the leadership states and references a `reading` field, and it covers access prerequisites and failure behavior. It does not fully describe the payload structure, but it is complete enough for an agent to decide to call it and understand the payment gate.

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

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

The tool takes zero parameters, so there is no parameter semantics to document. Per the rubric, a zero-parameter schema establishes a baseline of 4, and the description appropriately does not need to compensate.

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 and scope: 'X/SPY leadership states (GO / HOLDING / TURNING / OUT) for the 11 sector ETFs and every macro-book instrument,' recomputed intraday. It also explicitly labels itself the 'Live intraday version,' which distinguishes it from the sibling get_rotation without requiring 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?

It clearly frames the context for use as the live intraday rotation read and explains the subscription/payment prerequisites. It does not explicitly name get_rotation as the non-live alternative or state when-not to use this tool, so it falls short of full alternative routing.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description layers on real behavioral context the annotations cannot convey: latency/freshness ('one market day delayed'), sampling limits ('top 3 members, headline fields'), and fallback behavior for unrecognized input ('unknown values return the sector directory'). This is exactly the kind of extra disclosure that earns a top score.

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 dense paragraph, front-loaded with the response contents, then input format, then the free-sample constraint. Every clause carries information, though the run-on structure packs four distinct ideas together and could be broken up for faster scanning.

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 must carry return-value burden, and it does: it names the member list, counts, ETF row, and the degradation under the free sample. A caveat remains that 'ranked by opportunity' is never defined, but for a single-parameter read tool the definition is otherwise self-sufficient.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the terse schema text ('Sector name or sector-ETF symbol') by giving concrete accepted forms ('Energy', 'Information Technology', XLE, XLK) and documenting the behavior when the value is unknown. That conversion of the single parameter into actionable input guidance passes the 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?

States a specific verb+resource ('sector's drill-down') and enumerates exactly what the response contains (top 3 members ranked by opportunity, member count, count by state, sector ETF row). It distinguishes itself functionally, but never names the sibling get_sector_read_live, leaving the agent to infer the relationship from the 'free sample / one market day delayed' phrasing.

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

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

Usage is implied by the 'Free sample' clause: this is the delayed, limited variant, so a real-time consumer would want get_sector_read_live. However, the description never states when to pick this tool over its live sibling or any other board tool, so the routing decision is left to inference.

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

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

Annotations cover the safety profile (readOnly, non-destructive), and the description adds substantial behavioral context beyond them: the subscription model, the 7-day trial, the x402 pay-per-call path, and the exact failure mode (PaymentRequired object with no data). This is exactly the gating information an agent needs before calling.

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

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

Front-loaded with what the tool returns, then the live/subscription/payment mechanics. Four sentences, all earning their place, though the trial and connector-sign-in detail is slightly more than strictly necessary.

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 live, gated read tool with no output schema, the description covers the access model and fallback behavior adequately. It does not describe the shape of the returned ranking data, but the absence of an output schema makes that a minor gap.

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

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

Schema description coverage is 100% and the single 'sector' parameter is documented as 'Sector name or sector-ETF symbol'. The description adds no format, casing, or symbol syntax detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource: returns a sector's members scored and ranked from the current session. The phrase 'Live intraday version' distinguishes it from the non-live get_sector_read sibling without naming it explicitly, which keeps it just short of a 5.

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

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

Explains the access prerequisites clearly: subscription via Coil Live connector, or pay-per-call with an x402 wallet, otherwise a PaymentRequired object is returned. It implies use when live data is wanted, but does not explicitly route the agent to get_sector_read for non-live data.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavior: the 'one market day delayed' data freshness, the null-with-note outcome when a name is on neither list, and the error path where unknown symbols return the valid-symbol directory. These are real traits beyond the structured fields.

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

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

Front-loads the resource ('One stock's Coil read, headline fields') before the field enumeration, and the free-sample constraint is placed last. It is dense with long parentheticals, but each clause (value sets for entry window, null case, delay) carries information rather than 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?

With no output schema, the description carries the return-field burden and does so field-by-field, plus edge cases (unknown symbol, no-list null). Combined with annotations covering safety and idempotency, an agent has enough to call it correctly; only the missing sibling routing keeps it short of full marks.

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 symbol param, so baseline would be 3, but the description adds meaning the schema lacks: the valid coverage universe, 'one symbol per call', and the behavior on an unrecognized symbol. That materially sharpens what a valid input is.

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+resource ('One stock's Coil read') and then enumerates the exact fields returned (board-percentile band, entry window, hold label, leadership flag, price move, earnings days, regime). It also implies the sibling split from get_stock_read_live by noting the free sample is 'one market day delayed', though it never names that sibling directly.

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

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

No when-to-use or when-not-to-use guidance. The coverage note ('Covers any S&P 500, Nasdaq-100 or macro name') is scope, not routing guidance, and no alternative (e.g. get_stock_read_live, get_full_board, get_day_board) is named or contrasted. The agent must infer the choice purely from the delay clause.

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

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

Annotations cover the safety profile (readOnly=true, destructive=false, openWorld=true), so the description's job is to add context — and it does, disclosing the subscription/trial model, per-call x402 payment path, and the exact no-access behavior. It still does not explain the idempotentHint=false beside a readOnly read (i.e. that repeated calls return different live data), which would have closed the loop.

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

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

Front-loaded with what the tool returns before the access caveats, and every sentence carries information. The middle payment/subscription sentences are slightly dense but all necessary for correct invocation.

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?

There is no output schema, so the description must carry return-shape burden — and it names the returned fields (coil_score / coil_kind / coil_note) as well as the PaymentRequired failure object. For a single-parameter live read, nothing an agent needs to invoke it correctly is missing.

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

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

Only one parameter, and schema coverage is 100% with the ticker example 'NVDA' already in the schema. The description's 'One stock's ...' reinforces single-symbol scope but adds no format, case, or exchange-qualifier detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource ('One stock's current-session scores and entry state') and adds the distinctive payload (coil_score / coil_kind / coil_note). The phrase 'Live intraday version' explicitly separates it from the sibling get_stock_read, so an agent can choose between the two without opening a schema.

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

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

Gives concrete access conditions: Coil Live subscribers connect the connector and sign in, or an agent with an x402 wallet pays per call. It also states the failure mode when neither applies (PaymentRequired, no data), which implicitly routes the agent to the non-live sibling. It stops short of naming get_stock_read as the explicit fallback for unsubscribed callers.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so safety is covered. The description adds genuinely new context beyond them: the index itself is free and keyless, while the underlying full texts are gated and sold per-read via x402, which materially affects how an agent should treat the returned entries.

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, resource-first, with the payment/auth caveat trailing. The middle field enumeration (question, verdict, evidence class, data window, per-read price, address) is dense but each item earns its place by describing the payload.

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?

There is no output schema, so the description has to carry the return shape — and it does by listing the fields each study entry exposes. Combined with annotations covering safety, the definition is essentially complete for a parameterless listing 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?

With zero parameters there is nothing for the description to disambiguate, so the baseline for a 0-param tool applies. The description appropriately spends its words on the returned content instead.

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

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

It identifies a specific resource (the Coil Edge Research index) and enumerates what each entry contains, so an agent can tell it apart from the market/crypto/cart siblings. The verb is only implied by 'index' rather than stated, but 'every published backtest study' makes the listing behavior unambiguous.

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

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

Usage is only implied: 'Free and keyless' tells the agent it can call this without auth, and the note that studies are sold one read at a time over x402 hints at the browse-then-pay flow. It never explicitly states when to reach for this versus the board/read siblings, so the guidance stays implicit.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the description's job is to add context, which it does: a 40-entry cap, one-day TTL, MCP-session scoping, and no auth requirement. It does not describe pagination or what happens when the cap/TTL is exceeded, keeping it short of a 5.

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

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

The return shape and constraints are front-loaded in the first sentence, with the 'not a conversation history' clarification placed immediately after. There is mild redundancy between 'for this MCP session's cart' and 'scoped to this MCP session,' which keeps it from 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?

With no output schema, the description carries the return-shape burden and does so by describing each entry as key/value/category and capping the result at 40. Together with the TTL and session scope, an agent has enough to call it correctly; only the read-vs-save decision is left unaddressed.

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

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

Schema description coverage is 100% and the single optional param (skill_name) is fully documented in the schema, including the fact that it does not filter results. The description adds nothing about the parameter, so the baseline 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?

States a specific verb (returns) and resource (short shopping preferences stored for this session's cart), and explicitly rules out the most likely misreading with 'It is not a conversation history.' It stops short of naming the counterpart sibling (save_memory), which is the one ambiguity an agent would still need to resolve.

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 useful context (scoped to this MCP session, one-day retention, free/no key) that implies when reading is appropriate, but it never states when to call this versus save_memory or get_cart. Usage is inferable rather than instructed.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and repeat-call profile is covered structurally. The description adds only the word "Storefront" as domain context and nothing about behavior: it does not say whether the whole line is removed or a single unit decremented, nor what happens when product_id is absent from the cart. For a mutation tool, that silence about the core effect is a real gap.

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

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

The single short sentence is front-loaded with the domain prefix and wastes no words. It is, however, so terse that it crosses from concise into under-specified, leaving the reader with almost no usable content.

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

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

The tool is structurally simple (one required string parameter, no output schema, no nested objects), and the annotations cover idempotency and non-destructiveness, so an agent can call it correctly. What remains missing is the effect semantics (full-line removal vs. decrement) and the not-found case, which for a cart mutation is worth stating.

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

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

Schema description coverage is 0%, so the description carries the full burden for the single product_id parameter, yet it only says "a line" without connecting that to the parameter or clarifying whether it identifies a product, a variant, or a cart line. Nothing is added beyond the schema's type declaration.

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?

"Storefront: remove a line" gives a verb (remove) and an implied resource (a cart line item), which the tool name remove_from_cart disambiguates. However, "line" is never defined as a cart line item, and nothing in the text distinguishes this from update_cart_item, which is the nearest sibling that also mutates cart contents. The purpose is inferable but not stated with precision.

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

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

There is no guidance on when to use this versus update_cart_item (which could set quantity to zero) or get_cart, and no statement of preconditions such as the item already being in the cart. The agent must infer usage entirely from the name.

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

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

Annotations already declare a non-destructive, idempotent write, and the description adds substantial context beyond them: session-keyed storage, no-session no-op, one-day TTL then deletion, last-write-wins on repeated keys, and a hard cap of 40 entries. This is exactly the lifecycle behavior an agent needs before writing.

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

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

Purpose is front-loaded and the sentences are dense with distinct facts (scope, TTL, no-session behavior, overwrite, cap), so little is wasted. The single long semicolon-chained block is harder to scan than a short bulleted breakdown would be.

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 mutating tool with an output schema absent, the description covers the essentials: scope, lifetime, overwrite semantics, capacity limit, and cost. It does not describe the success/failure response or what happens when the 40-entry cap is reached, which are minor residual gaps given annotations cover the safety profile.

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

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

Schema description coverage is 100%, so key, value, and category are already documented with examples and length limits in the schema. The description restates the notion of a short preference but adds no syntax, format, or constraint detail beyond the schema, making the baseline 3 appropriate.

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

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

States a concrete verb and resource: stores one short shopping preference keyed to the cart for the session, with illustrative examples (product, billing period). It distinguishes itself from generic memory via 'It is not conversation storage', but never names its natural counterpart recall_memories, so the sibling boundary is only partially drawn.

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

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

Gives clear situational context (session-scoped cart preferences, one day lifetime) and one explicit exclusion ('not conversation storage'; no session means nothing is stored). It stops short of routing the agent to recall_memories for retrieval or stating when saving is unnecessary, so usage is implied rather than fully 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful fact that results span policies, promotions, and risk disclosures, but says nothing about result ranking, document scope limits, or freshness.

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

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

A single compact sentence with no filler, and the domain scope is front-loaded. It is a fragment rather than a sentence, but it is not padded or redundant.

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 search tool with two undocumented parameters, no output schema, and no usage guidance, the description leaves too much to inference. An agent cannot tell what to pass as the query or how product_ids changes 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?

Schema description coverage is 0%, so the description carries the full burden for 'query' and 'product_ids' — and it provides none. It never explains what the query string should contain or that product_ids scopes policies to specific products, leaving both parameters semantically undocumented.

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

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

The description names the content domain (refunds, cancellation, delivery, merchant of record, risk disclosures, privacy, promotions) so an agent can infer this retrieves storefront policy text, which does distinguish it from search_products. But it never states the action — no verb like 'search' or 'retrieve' — and reads as a topic list appended to a vague 'Storefront:' label rather than a purpose statement.

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

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

There is no guidance on when to call this versus siblings such as search_products or get_product_details, and no mention of what kinds of queries are appropriate. The topic list hints at coverage but gives no usage 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds output shape ('product families with a from-price and their billing variants'), which is useful, but says nothing about result count, pagination, or empty-result 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?

Two sentences, front-loaded with the 'Storefront:' scope marker and then the return shape. No filler and every clause carries 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, describing the return shape is necessary and done. However, for a search tool the missing guidance on query semantics and 'limit' is a real gap that annotations cannot fill.

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 either parameter. It never explains what 'query' matches (product name, keyword, SKU?) or what 'limit' controls, leaving both params undocumented in both places for a tool that requires one.

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 ('search Coil's two products') and enumerates the catalog (Coil Scanner, Coil Live), so an agent knows exactly what is being searched. It does not explicitly contrast with the sibling get_product_details, so sibling differentiation is only implicit.

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 never says when to use this tool versus alternatives such as get_product_details, nor any prerequisites or exclusions. Usage must be inferred entirely from the word 'search'.

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

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

The annotations declare destructiveHint=false, meaning only additive updates, but the description explicitly says setting quantity to 0 removes the line item. Removal is a destructive update, so the description directly contradicts the structured annotation. Per the rubric, this is an annotation contradiction.

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

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

A single front-loaded sentence with no filler. The critical edge-case behavior is stated immediately, making it easy to parse and act on.

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

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

For a simple two-parameter cart update with full annotation coverage, the description covers the most important behavioral surprise (quantity clamping/removal). It omits product_id format details and any mention of return values, but no output schema exists and the core behavior is covered.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the quantity parameter's semantics well (0 removes, values >1 are held at 1), but it does not describe the product_id parameter beyond implying it identifies a cart line.

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 specific verb+resource ('set a line's quantity') and clarifies the tool's scope as a storefront cart update. It does not explicitly differentiate from sibling tools like remove_from_cart or add_to_cart despite the overlap created by the '0 removes' behavior.

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 edge-case behavior ('0 removes; anything above 1 is held at 1') implies how the tool is used, but no explicit when-to-use or when-not-to-use guidance is given. It does not name alternatives or say when to prefer remove_from_cart instead.

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