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

The annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds useful context that this is a live account action affecting real funds or account state, but it does not explain irreversibility, quote consumption, permissions, or downstream effects.

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

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

The description is short and front-loads the live-account risk warning. Every sentence carries some value, though the brevity is also the source of its incompleteness.

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

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

This is a destructive, non-idempotent mutation with three required parameters and a nested body, but the description does not explain parameter roles, quote lifecycle prerequisites, or what acceptance entails. Annotations help, but for a live trading action with 0% schema description coverage, the definition remains under-specified.

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

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

Schema description coverage is 0%, so the description must compensate for the three required parameters, including the nested body with acceptedSide. It only vaguely hints at 'one side' and does not explain rfqId, quoteId, or how acceptedSide should be understood beyond the schema enum.

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

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

The description states a specific verb and resource: accepts one side of a quote. It is clear what the tool does, but it does not distinguish the action from closely related siblings such as confirm_quote, create_quote, or delete_quote.

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

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

The description gives no explicit guidance on when to use this tool versus confirm_quote or other quote lifecycle tools. The 'LIVE ACCOUNT ACTION' warning provides risk context but not usage selection criteria or prerequisites.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so safety is covered structurally. The description adds the real-funds/account-state consequence, which is meaningful context, but says nothing about reversibility, whether partial failure is possible across many orders, or what the response reports.

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

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

Two short sentences with the dangerous-operation warning front-loaded, which is the right ordering. Minor flaw: the sentences run together without punctuation between 'slugs' and 'This operation', slightly hurting readability.

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

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

With a single fully documented body parameter and rich destructive annotations, the core call is adequately covered. The gaps are moderate: no differentiation from the other cancel tools and no hint about the outcome of a bulk cancel, which matters for a non-idempotent destructive operation.

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

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

Schema description coverage is 100% and the schema itself explains that an empty slugs array cancels all orders. The description's 'optionally filtered by market slugs' merely restates the schema without adding format or edge-case detail, 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 ('Cancel all open orders') plus the scope modifier 'optionally filtered by market slugs', which is clear enough to act on. It does not, however, distinguish itself from close siblings like cancel_order, cancel_multiple_orders, or modify_multiple_orders, leaving the agent to infer the boundary.

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

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

The 'LIVE ACCOUNT ACTION' prefix signals this is a real-money mutation, which implicitly nudges caution, and the slug filter implies bulk-cancel-everything is the default behavior. There is no explicit when-to-use versus cancel_multiple_orders or cancel_order, and no stated prerequisite such as authentication scope.

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 past the annotations (destructiveHint, openWorldHint, idempotentHint=false) by disclosing batch atomicity on request-shape validation ('the whole batch is rejected by the gateway'), that the exchange may silently ignore unknown orderIds, and that canceledOrderIds is only an echo of the request. It also tells the agent where truth lives, the order stream, which annotations 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 the live-account warning, then layers validation, silent-ignore, and return-value caveats in a tight sequence. The closing line ('Returned IDs may not confirm exchange execution; verify the outcome') restates the earlier 'echo of the request, not a confirmation' point, so the last sentence is partly 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 destructive, non-idempotent batch mutation with no output schema, the description covers everything an agent needs: real-funds risk, all-or-nothing validation, per-item silent-ignore behavior, and the fact that the response is not confirmation. No material gap remains for correct invocation or outcome verification.

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 already documents orderId, marketSlug and the 1-20 bound, so the baseline is 3. The description earns above baseline by adding semantics the schema cannot: unknown orderIds may be silently ignored and the echoed IDs are not proof of execution. That changes how an agent constructs and trusts the request body.

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 with a hard scope bound: 'Cancel up to 20 orders in a single request.' That bound plus the batch framing distinguishes it from single-order cancel_order and from cancel_all_open_orders without needing to open any schema.

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

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

Usage context is implied by 'LIVE ACCOUNT ACTION' and the batch limit, so an agent knows this is a production mutation for a known list of orders. However, no sibling is named and no explicit condition says when to prefer this over cancel_order or cancel_all_open_orders. The guidance about verifying on the order stream is about behavior, not tool selection.

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

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

The annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the description's 'may affect real funds' warning largely restates the safety profile. It does add the useful LIVE ACCOUNT framing, but leaves the non-idempotent behavior unexplained (e.g. what an error or no-op looks like when re-canceling) and says nothing about the response.

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

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

Two short, front-loaded sentences with the risk warning first. The only friction is the missing sentence break between 'ID' and 'This', which makes it read as one run-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 destructive mutation with a nested body and no output schema, the description covers the safety headline but leaves out return values, error conditions for already-terminal orders, and the optionality of marketSlug. Adequate given the rich annotations, but not complete.

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

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

Schema description coverage is 100%, and the schema already documents orderId as the 'Exchange-assigned Order ID to cancel' and marketSlug, so the description adds essentially no meaning beyond it. Notably it does not mention that marketSlug inside the required body is optional, which is the one non-obvious parameter nuance.

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

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

The description gives a specific verb and resource ('Cancel a specific order') and identifies the key ('exchange-assigned ID'), which lets an agent distinguish this from cancel_all_open_orders and cancel_multiple_orders by the singular scope. It stops short of explicitly naming those siblings, but the singular/plural distinction is reasonably inferable.

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: cancel one known order when you have its exchange ID. There is no explicit guidance on when to prefer cancel_multiple_orders or modify_order, no prerequisites (e.g. order must be open), and no note about what happens if the order already filled or was already canceled.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the risk profile is conveyed structurally. The description adds useful context beyond that: it is a live-account action that sells ALL contracts in the market, implying no partial close. It does not cover permissions, failure behavior, whether the resulting order can be canceled, or how slippage/maxBlockTime affect execution.

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

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

Three short sentences with the risk warning front-loaded via the 'LIVE ACCOUNT ACTION:' prefix, followed by the effect and the fund impact. Nothing is redundant or padded.

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

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

This is a destructive live-trading mutation with a nested parameter object and no output schema, so the description carries weight. It explains the core effect but omits what the agent gets back (order id, status), what happens if the position is absent or execution fails, and how the synchronous path interacts with maxBlockTime.

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% for the single nested body object and its fields, so the schema already explains marketSlug, slippageTolerance, maxBlockTime, and synchronousExecution. The description adds no parameter-level meaning, 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?

The description names a specific verb and resource ("Create an order to close an existing position in a market") and clarifies the effect: it sells all contracts in that market. That is enough to distinguish it from the sibling create_order for most agents, though it never explicitly contrasts the two.

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 phrase 'to close an existing position', which tells the agent the situation this tool is for. However, there is no explicit guidance on alternatives (create_order, preview_order for a dry run, or cancel/modify), no prerequisites such as having an open position, and no note on when not to use it.

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

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

The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description reinforces this with 'LIVE ACCOUNT ACTION' and 'may affect real funds', which is useful emphasis but largely restates the destructive hint. It does not explain what 'last look' means, what state changes on confirm, or whether the action is reversible.

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

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

Two short sentences with the risk warning front-loaded in capitals, so the agent sees significance immediately. The wording is efficient, though the undefined term 'last look' consumes space without conveying actionable information.

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

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

This is a destructive, open-world, non-idempotent mutation on a live account with an undocumented nested body object and no output schema. The definition supplies almost none of what an agent needs to call it safely: no body contract, no response shape, no failure conditions.

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% for three required parameters, including a nested free-form 'body' object, so the description carries the full burden and provides nothing. Nothing explains what rfqId and quoteId identify, or what fields 'body' must contain.

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

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

The description states a specific verb and resource: 'Confirms an accepted quote during last look.' That is clearly distinct from create_quote, get_quotes, and delete_quote. It is less clearly distinguished from accept_quote, which sits in the same family and is never mentioned.

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

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

The only usage context given is 'during last look', which is unexplained domain jargon. There is no guidance on when to confirm versus accept_quote, what prerequisite state the quote must be in, or what happens if the last look window has passed.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds genuinely non-derived behavior: a 1,000-per-week creation quota per exchange participant, a Monday 00:00 UTC reset, and the fact that returning an existing canonical combo is quota-free. The explicit warning that the operation may affect real funds or account state is useful reinforcement. Slight tension with idempotentHint=false is resolved by the quota framing, so it is not a contradiction, but the description could state more clearly what the returned instrument represents.

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 live-account warning and the core verb, then layers quota rules in a logical order. Five sentences with no filler, though the quota detail could be trimmed to two sentences without losing decision-relevant 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?

Rich annotations plus no output schema mean the description need not restate the safety profile, and the quota disclosure is exactly the kind of context an agent needs before a destructive call. Still missing for a nested-payload mutation: what a 'combo instrument' actually is (a multi-leg combined position), what the response contains, and whether legs must be from the same event.

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 single parameter is a nested object with a required 'legs' array (2-50 items, each with symbol and side). The description only says 'for the supplied legs' and adds no meaning about leg ordering, weighting, or what constitutes a valid combination — the schema alone carries all of that. For a nested payload at 0% coverage, this is a clear 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?

States a specific verb and resource: 'Creates or returns the combo instrument for the supplied legs.' That is clearly distinguishable from get_combos (read-only retrieval) and from create_order. It falls short of a 5 because the create-vs-return duality, which is the tool's most consequential distinction, is only clarified later in the quota paragraph rather than in the opening sentence.

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 context is implied through the quota rules and the 'LIVE ACCOUNT ACTION' label, so an agent knows this is a live-account mutation with a weekly budget. However, the description never routes the agent explicitly, e.g. 'use get_combos to read existing combos' or 'use create_order for single-leg orders,' leaving sibling 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 flag destructive/openWorld/non-idempotent, and the description still adds materially new behavior: request-shape validation rejects the entire batch before reaching the exchange, per-entry accept/fill/reject outcomes arrive on the order stream rather than in the response, and createdOrderIds preserve request order. That is exactly the context an agent needs and cannot get from the schema.

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

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

Five short sentences with zero filler, and the highest-stakes fact ('LIVE ACCOUNT ACTION') is front-loaded before any mechanics. Each sentence delivers a distinct operational fact: limit, validation failure mode, outcome delivery channel, ID ordering, and funds risk.

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 correctly compensates by explaining what the response does and does not contain (createdOrderIds only; fills on the stream). It omits prerequisites such as authentication, permissions, or rate limits for a batch of 20 destructive writes, which keeps it just short of complete.

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

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

Schema description coverage is 100%, so the nested order fields (tif, intent vs outcomeSide+action, price, cashOrderQty, slippage) are already documented inline. The description adds nothing about entry-level semantics, 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?

The description states a specific verb and resource ('Create up to 20 orders in a single request') and makes the batch scope explicit, including the 1-20 limit. What it lacks is any naming of a sibling (create_order for singles, preview_order for dry runs), so the agent must infer routing from the name 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?

Usage is only implied: the batch cap and the LIVE ACCOUNT ACTION banner suggest when batching is appropriate, but there is no explicit guidance on when to prefer create_order for a single order or preview_order to validate before committing real funds. Given the sibling set contains both, that omission is a real 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 destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds a real-funds/account-state consequence warning, which reinforces but does not extend that picture. It says nothing about blocking behavior with synchronousExecution, rejection semantics for participateDontInitiate, or irreversibility of a filled order.

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

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

Two short sentences, with the highest-stakes information front-loaded in the leading clause. The missing sentence break between 'market' and 'This' is a minor blemish, and the brevity borders on under-specification for a tool this consequential.

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

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

This is a high-complexity, real-money mutation with a deeply nested 15+ field request body and no output schema, yet the description covers none of it: no explanation of the order lifecycle, what is returned on acceptance vs rejection, or how synchronousExecution and maxBlockTime interact. For a destructive trading tool, the description is far thinner than the complexity demands.

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 nested body properties are documented in detail (intent vs outcomeSide+action, cashOrderQty for market orders, slippage ticks priority). The description adds no parameter meaning whatsoever beyond the schema, 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 ('Create a new order to enter into a market') and flags it as a live-account action, so the agent knows exactly what it does. It does not distinguish this from close siblings such as create_multiple_orders, preview_order, or close_position_order, so the agent must infer the boundary itself.

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

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

The only guidance is the 'LIVE ACCOUNT ACTION' warning, which signals risk but not when to choose this tool over preview_order (dry run), create_multiple_orders (batch), or modify_order (amend). No exclusions, prerequisites, or alternatives are named despite several obvious 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 disclose destructive, non-idempotent, open-world write behavior, so the bar is lower. The description still adds real value: every successful call returns a new quoteId even for replacements (important non-idempotency detail) and it requires an authenticated Retail account, though it says nothing about permissions, rate limits, or failure modes.

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

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

Three short sentences with the most important warning ('LIVE ACCOUNT ACTION') front-loaded, followed by return-value behavior and a pointer to the relevant doc. No filler.

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

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

It correctly covers that a quoteId is returned and that the action is live and fund-affecting, which is the key context for a nested-object mutation tool with no output schema. It is still incomplete on the nested parameter semantics and on prerequisites such as rfqId sourcing, which matter for this complexity.

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 reported at 0%, and the nested body fields (rfqId, restRemainder, postOnly) are undocumented in both schema and description. The description carries none of the burden of explaining what rfqId refers to or what restRemainder/postOnly control, leaving the agent to guess on a fund-affecting call.

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

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

The description states a specific verb and resource ('Creates a quote') and ties it to the authenticated Retail account, which is enough to distinguish it from neighboring read tools like get_quotes. It does not explicitly contrast with create_rfq or accept_quote, so sibling differentiation is only partial.

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 ACCOUNT ACTION' prefix and the note about real funds/account state imply this is a high-stakes write to be used deliberately, and the link points to replacement behavior. However, there is no explicit when-to-use/when-not guidance or mention of alternatives such as accept_quote or confirm_quote.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered structurally. The description adds genuinely useful context beyond that: it is a live-money action tied to the authenticated Retail account. It does not explain the RFQ lifecycle, what is actually created, or what happens to existing state, so it stays at an adequate level rather than rich.

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

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

Two tight sentences with the highest-severity warning front-loaded in capitals. No filler or repetition, though the second sentence partially restates the danger already implied by the first.

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

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

Given no output schema and complex nested parameters, the definition is not fully complete. It covers the critical real-funds warning and account scope, but omits parameter meaning and any indication of the RFQ response or subsequent quoting flow. This is a meaningful gap, though not fatal for a destructive action where safety warning and authentication context are the key facts.

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 single body parameter is a nested object with a oneOf constraint (qtyDecimal vs cashOrderQty) plus symbol and restRemainder. The description says nothing about any of these fields, so it does not compensate for the coverage gap in the schema. An agent gets no help understanding quantities, symbol format, or what restRemainder means.

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

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

The description uses a specific verb and resource ("Creates a combo RFQ") and scopes it to the authenticated Retail account, which an agent can act on. It stops short of distinguishing this from the sibling create_combo or create_quote, so the boundary between those operations is not made 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?

There is no statement of when to use this tool versus alternatives such as create_combo, create_quote, or preview_order, and no prerequisites beyond the account mention. The agent must infer the workflow entirely from sibling names.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds real value with the 'LIVE ACCOUNT ACTION' warning and the consequence that the quote can no longer be accepted, but it omits irreversibility, required permissions, and what happens to the parent RFQ.

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

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

Two short sentences with the live-account warning front-loaded, which is the right priority for a destructive tool. The second sentence is somewhat generic but still earns its place as a risk cue.

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 destructive delete with no output schema, the annotations plus description cover the essentials. However, an agent is left guessing about state requirements, error conditions, and the scope of impact on the associated RFQ.

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 both parameters (rfqId, quoteId) are undocumented in the schema. The description does not compensate at all, never explaining that rfqId scopes the quote or that quoteId identifies the specific quote to remove.

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 ('Deletes') and resource ('a quote') and states the resulting effect ('so it can no longer be accepted'), which distinguishes it from delete_rfq and cancel_order. It stops short of explicitly contrasting with those siblings, so it is clear but not fully differentiated.

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

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

There is no guidance on when to delete a quote versus using delete_rfq, accept_quote, or confirm_quote. No preconditions are stated, such as whether the quote must be pending or whether an already-accepted quote can be deleted.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is largely supplied. The description's "LIVE ACCOUNT ACTION" and "may affect real funds or account state" restate that destructive framing rather than adding new information such as what happens to outstanding quotes on the RFQ or whether closing is reversible.

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

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

Two short sentences with the action front-loaded, and the critical warning placed early. The second sentence is somewhat boilerplate, but nothing is padded or redundant enough to hurt selection.

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

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

This is a destructive, non-idempotent mutation with an undocumented required identifier and no output schema. The description omits what state the RFQ must be in, what happens to linked quotes or trades, and what a successful response confirms — significant gaps for a fund-affecting operation.

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

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

Schema description coverage is 0% for the single required parameter rfqId, and the description says nothing about it — no format, no source, no indication of whether it refers to the RFQ's own identifier versus a quote or user id. Unlike the zero-parameter baseline, here the description needed to compensate and does not.

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?

"Closes an open RFQ" gives a specific verb and resource, but it does not reconcile the mismatch with the tool name (delete_rfq), nor does it distinguish the operation from adjacent RFQ lifecycle tools such as create_rfq, accept_quote, or confirm_quote. An agent can infer the target object but must guess at the exact semantics of 'close' versus 'delete'.

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 this should be called, what preconditions must hold (e.g., the RFQ must still be open), or which sibling to use instead. The only usage-adjacent content is a generic live-account warning, which is not a when-to-use rule.

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 gap-fill semantics (close carried forward, tick_count 0), clamp-rather-than-reject behavior for from/to, the empty-series vs 404 failure split, and that unknown classes are rejected. The ordering caveat ('match by asset field, never by position') is exactly the non-obvious behavior an agent could not infer from 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?

It is front-loaded with the return shape and generation rules, then moves to limits, then to error/ordering handling—every sentence carries information. It runs long as a single block, and the dedupe sentence partly restates the schema's own duplicate note, so it is slightly less lean than it could 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 nested single-parameter tool with full schema coverage and no output schema, the description supplies the return semantics (per-series asset field, echoed bounds, empty vs 404 cases) that would otherwise be unstated. Nothing needed to call it correctly or interpret the response 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?

Schema coverage is already 100%, so the schema documents to, from, assets and bucket individually; the description still adds cross-parameter meaning the schema lacks, such as the 3600-candle cap constraining effective from/to and the dependence of usable window width on bucket size. It also notes dedupe and the echoed effective bounds, though it does not restate per-field formats.

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

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

The description opens with a specific verb and resource: 'Returns a dense, ascending OHLC candle series per requested asset between from and to, one candle per bucket.' It pins down scope (gap-filled buckets, per-asset series) so an agent can tell it apart from a general price-history 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?

It gives clear operational context, including how the 3600-candle cap interacts with bucket choice ('an hour at 1S, 60 hours at 1M, 150 days at 1H'), which guides widening/narrowing decisions. It never explicitly contrasts this tool with the sibling get_price_history or names a when-not condition, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description still earns credit by disclosing what the payload contains (buying power, asset values, pending transactions), which is the main behavioral unknown for a no-parameter read with no output schema. It does not mention authentication requirements or per-account scoping.

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 redundant wording; the resource leads and the returned components follow. Nothing could be removed without losing 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 read with no output schema, the description supplies the essential missing piece — what comes back. What remains unstated is whose balances are returned absent any account identifier (implying the authenticated user) and how this differs from position-level siblings.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies no inputs are needed by framing the call as an unfiltered snapshot of the user's own account.

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 user's current account balances") and enumerates the contents: buying power, asset values, pending transactions. That differentiates it from order/position tools by implication, though it never explicitly contrasts with the nearby get_user_positions or get_your_incentive_earnings siblings.

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 by the word "current" and the enumerated outputs — an agent can infer this is the snapshot/overview call. There is no explicit when-to-use statement, no guidance on refresh cadence, and no note distinguishing it from get_user_positions when the agent needs position-level detail.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds the kinds of records returned, which is useful. However, it says nothing about pagination behavior or result ordering beyond what the schema already documents.

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, and the core content comes first. It is perhaps too terse given the tool's filtering surface, but nothing is wasted.

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

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

For a read-only, well-annotated listing tool whose parameters are fully documented in the schema, the description is sufficient to call it correctly. The absence of an output schema is partly offset by naming the activity categories, though the full set of nine types is not enumerated.

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 every nested query field (limit, types, cursor, sortOrder, marketSlug) is documented inline with examples. The description contributes no additional meaning about filtering or pagination semantics, 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 (get) and resource (activities) and names examples of what those activities are: trades, position resolutions, account balance changes. It does not distinguish this list-of-activities tool from related siblings such as get_user_positions or get_account_balances, so an agent must infer the boundary.

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

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

No guidance on when to use this tool instead of the position or balance siblings, and no prerequisites or exclusions are stated. The only implied usage is that scoping is 'for a user', which the agent has to interpret on its own.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds only the 50-per-page pagination constraint; it says nothing about ordering, total counts, or how iteration through pages should proceed, which matters for a listing endpoint.

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. It is appropriately sized, though the parenthetical pagination note duplicates schema information rather than adding new context.

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

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

For a simple read-only listing tool with full schema coverage and rich annotations, the definition is adequate but thin. It omits what a league record contains, whether results are ordered, and that only pagination controls exist because no filter parameters are offered, leaving the agent to discover these from the schema or first call.

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%, with both limit (max 50, default 50) and offset (default 0) documented in the nested query object, so the baseline is 3. The description merely restates the max-50 limit already present in the schema and adds no meaning about offset semantics or page iteration.

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

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

The description uses a specific verb and resource ('Retrieve leagues') and adds a pagination scope. It is clear what the tool returns, but it never distinguishes itself from siblings such as get_league_by_slug or get_events_by_league_slug beyond the plural 'all' in the name.

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

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

There is no guidance on when to use this listing tool instead of get_league_by_slug for a single league, nor any mention that no filtering (e.g. by sport) is supported. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered elsewhere. The description adds nothing beyond them — no note on whether the result is cached, ordered, paginated, or how large the catalog typically is, which is the kind of context that would earn credit.

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 four-word sentence with the verb front-loaded and zero waste. It is not padded, though its terseness borders on under-specification rather than disciplined brevity.

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

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

For a parameterless read tool with no output schema, the description is minimally sufficient, but it should at least clarify the relationship to get_sports and what a 'sport' record is (slug, name) so the agent knows how to chain into get_events_by_sport_slug. That unresolved sibling ambiguity is the main completeness gap.

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

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

The tool takes zero parameters and the schema is empty, so there is no parameter semantics for the description to explain. The baseline of 4 applies; nothing in the description misrepresents the no-argument nature of the call.

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?

"Retrieve all sports" names a clear verb and resource, so the basic purpose is unambiguous. However, the sibling list contains both get_sports and get_sport_by_slug, and this description does nothing to explain how 'all sports' differs from the sibling get_sports — the agent cannot tell which to pick 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?

No when-to-use guidance at all: nothing says whether this is a catalog enumeration to call before get_events_by_sport_slug, or how it relates to get_sports / get_all_leagues. No exclusions or alternatives are named, so the choice between the near-duplicate siblings 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 readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds only exact-match lookup behavior and says nothing about missing-symbol errors, response shape, or pagination. With annotations carrying the behavioral load, this is adequate but thin.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately sized for a simple lookup tool.

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

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

For a one-parameter read-only lookup, the definition plus annotations and schema are enough to call the tool. It lacks return-value detail, but no output schema exists and the operation is straightforward; the remaining gap is minor.

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

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

Schema coverage is 100% and there is only one required nested parameter, so the schema already documents the query.symbol structure. The description adds useful semantics by saying the match must be exact rather than fuzzy, which is not explicit in the schema. It does not explain the nested query wrapper, but that is visible in the schema.

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

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

The description uses a specific verb ('Returns') and resource ('combo'), and the 'exact symbol' qualifier signals a precise lookup. It does not explicitly distinguish itself from other get_* siblings, and the plural tool name versus singular 'the combo' introduces minor ambiguity.

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

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

It implies the tool is for exact-symbol lookups but gives no when-to-use guidance, no prerequisites, and no alternatives such as create_combo or other retrieval tools. An agent must infer usage from the name and schema alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds nothing beyond that — no mention of what the nested query options do to the response, whether unknown IDs error or return empty, or how large the returned event payload is.

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 repetition. It is efficient, though its brevity is partly the source of the gaps in other dimensions rather than pure economy.

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 should say more about what an event record contains, but the fully documented input schema and complete annotations cover the mechanics of calling it. An agent can invoke it correctly; it just cannot predict the response shape or why to prefer it over sibling lookups.

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

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

Schema description coverage is 100%, so both the id field and the nested query object (groups, comboEnabledOnly, includePopularPlayerProps) are documented in the schema. The description adds no meaning beyond that, which meets the baseline of 3 when the schema carries the load.

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

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

The description gives a specific verb and resource ("Retrieve a specific event by its ID"), so an agent knows exactly what the tool returns. However, it does not distinguish this from siblings like get_event_by_slug or get_event_by_partner_external_id, which look up the same resource via a different key.

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

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

There is no guidance on when to use this tool versus the other event lookups in the sibling list. The agent must infer from the parameter name alone that this is the ID-based variant, with no stated exclusions or preference rules.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond those: the call is a resolution/translation step and the payload includes the mapped market sides, not just the event. It does not say what happens when the external ID is unknown, which keeps 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?

A single sentence with no filler, front-loading the action and the input, then stating the output. Nothing is redundant or buried.

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 usefully summarizes the return shape (internal event plus mapped market sides), which is the key thing an agent needs. The remaining gap is failure behavior for an unresolvable partner ID or an unrecognized partner slug, minor for a two-parameter read-only lookup.

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 both parameters (externalId, partnerKey) are documented with examples in the schema itself, so the baseline of 3 applies. The description's 'e.g. OpticOdds fixture ID' merely restates the schema's own example and adds no new semantics about format or constraints.

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 ('Resolve') and specific resource ('a partner external event ID ... to the internal event and its mapped market sides'), and the word 'partner external' distinguishes it from siblings get_event_by_id and get_event_by_slug, which take internal identifiers. An agent can pick the right tool 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?

Usage is implied rather than stated: the 'partner external event ID' framing tells the agent to use this when it holds a third-party ID instead of an internal one, but there is no explicit when-not clause and no sibling is named as the alternative for internal IDs. Adequate but leaves the routing inference to the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no mention of response shape, error behavior for missing slugs, or the effect of the nested query options such as groups or comboEnabledOnly.

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 short sentence with no wasted words and the resource front-loaded, but it is under-specified rather than efficient — brevity here comes at the cost of useful information.

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

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

For a tool sitting among three near-identical event getters and carrying a nested query object, the description is too thin. It should name the alternative identifier-based siblings and at least gesture at what the query flags change in the response.

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

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

Schema description coverage is 100%, so both the slug and the nested query object fields are already documented in the schema. The description adds no extra meaning about the nested query object, 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?

The description names a clear verb and resource (retrieve an event) and implicitly keys on slug, which separates it from get_event_by_id and get_event_by_partner_external_id. However, it is close to a restatement of the tool name/title and never explicitly distinguishes itself from those sibling getters.

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 pick this over get_event_by_id, get_event_by_partner_external_id, or get_events. Nothing is said about what happens with an unknown slug or when the optional query flags should be used.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds nothing beyond that: it does not mention pagination defaults (limit/offset), the default exclusion of hidden events, or anything about result volume, but with annotations doing that work a 3 is the baseline rather than a failure.

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 three-word sentence has zero filler and nothing buried, but its brevity is under-specification rather than conciseness — it omits everything an agent needs to know about scope. Front-loading is fine; content is not.

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

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

For a tool with a deeply nested 55-parameter query object, no output schema, and many overlapping siblings, a three-word description is far from complete. The schema covers parameters, but nothing explains what an "event" is here, how results are paginated, or what the default filtering (e.g. includeHidden) does.

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 every one of the nested query filters is documented inline, including the tricky tag_slugs_all AND-vs-OR contrast. Baseline 3 applies: the description contributes no parameter meaning, but the schema does the heavy lifting.

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

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

"Retrieve all events" essentially restates the name/title (Get Events) with no added specificity. The word "all" is actively unhelpful for a tool whose schema exposes ~55 filter parameters, and it does nothing to distinguish this from siblings like get_events_by_sport_slug, get_events_by_league_slug, get_events_for_a_tag, get_event_by_id, or get_sports_events.

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 guidance whatsoever — no statement of when to call this generic event lister versus the many filtered-by-sport/league/tag siblings. The absence is significant because the sibling set is dense with near-duplicate event retrieval tools, so an agent gets no routing help.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered without the description. The description adds one genuinely useful behavioral fact — that the league is resolved to its active series before events are returned — but says nothing about pagination behavior, result ordering, or what happens when a league has no active series.

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

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

Two short sentences with no filler, and the essential scoping information comes first. It could be marginally stronger by folding the sibling differentiation into the same opening sentence, but nothing is wasted.

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

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

For a read-only lookup with a fully documented nested query object and no output schema, the description covers the core mechanics plus the non-obvious series resolution. The remaining gaps — return shape and pagination semantics — are either minor or handled by the schema.

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

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

Schema description coverage is 100%, including the nested query object's type, section, limit, offset and excludeEventId fields, so the schema already carries the parameter burden. The description only repeats the slug example ('nfl', 'nba') already present in the schema and adds no meaning about defaults or interplay between the nested fields.

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 ('Retrieve') and resource ('events for a league'), plus scope ('by its slug') and the internal resolution step ('resolves the league to its active series'). This distinguishes it from get_event_by_slug and get_events, though it never names the closest sibling get_events_by_sport_slug to make the league-vs-sport split 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?

Usage is only implied: an agent infers it should call this when it holds a league slug rather than a sport slug or a specific event identifier. There is no explicit when-to-use or when-not-to-use guidance and no mention of the alternative sibling that takes a sport slug instead.

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, and open-world behavior, so the description does not need to restate safety. What it does add is genuinely useful beyond the annotations: the tool fans out across all leagues and then their active series, meaning the result is an aggregate and only covers active series. That fan-out cost and the active-only scope are disclosed nowhere else.

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

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

Two tight sentences with zero filler. The action and the slug parameter come first, and the aggregation mechanics follow as supporting 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?

There is no output schema, so the description must indicate what comes back; it does say 'returns combined events,' though it does not describe the event shape or ordering. For a simple lookup tool with a fully documented schema and strong annotations, that is nearly complete.

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

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

Schema description coverage is 100%, so the schema already documents slug, query.type, limit, offset, section, and excludeEventId. The description only restates the slug examples, which is redundant, and adds nothing about the nested query options. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description gives a specific verb and resource ('Retrieve events for a sport by its slug') and adds the mechanism: it fetches all leagues for the sport, collects their active series, and returns combined events. It does not explicitly contrast itself with the near-identical sibling get_events_by_league_slug, 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?

The slug examples ('football', 'basketball') imply the use case, but there is no statement of when to choose this tool over get_events, get_events_by_league_slug, or get_sports_events, all of which are present in the sibling list. No exclusions or prerequisites are given.

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

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

Annotations already supply the full safety profile (readOnlyHint, idempotentHint, non-destructive, openWorld), so the description's main addition is the default sort ('volume descending'), which is genuinely useful behavioral context. However, that default is also restated in the schema's orderBy description, and the description says nothing about default result set size, pagination behavior, or whether only active events are returned by default.

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 zero waste: the resource, the filter, and the default ordering appear in reading order of importance. Nothing is padded or restated.

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

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

For a simple read-only list tool with full schema coverage, rich annotations, and no output schema, the definition covers the essentials: what it returns, the key filter, and the default sort. Minor gaps remain around pagination expectations and the default active/closed filtering, which are only discoverable in the schema.

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

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

Schema description coverage is 100%, including the nested query object with limit, offset, active, closed, orderBy, and orderDirection, so the schema already does the heavy lifting. The description adds only the default ordering behavior and nothing about how slug values are formed or how the nested query object should be composed.

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 events') plus the discriminating filter ('filtered by tag slug'), which separates it from the many sibling list tools such as get_events_by_sport_slug and get_events_by_league_slug. It does not explicitly name an alternative, but the tag filter alone makes the tool's identity 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: an agent can infer it should call this when it has a tag slug rather than a sport/league slug. There is no explicit when-to-use framing, no mention of the sibling alternatives, and no note on when to prefer get_events or get_events_by_league_slug instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds two pieces of non-annotated behavior: the result scope (active plus historical programs, not just live ones) and the response organization (grouped by market). Because there is no output schema, that grouping hint is genuinely useful, but it stops short of describing result shape beyond grouping or pagination 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 — scope and return organization in one clause. It is efficient, but the terseness leaves the awkward nested "query.query" parameter entirely unaddressed, which the description could have clarified in the same sentence.

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

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

For a read-only listing tool with 100% schema coverage and no output schema, the minimum is met: the agent knows what is returned and roughly how it is organized. However, a nested 11-field query object with pagination and no output schema warrants at least a note on the paginated response (next_page_token), which the description never mentions.

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%, with every nested field (symbols, statuses, program_type, page_token, etc.) documented in the schema itself. The description adds no filter semantics, defaults, or interaction notes beyond what the schema says, 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?

"Returns ... incentives grouped by market" names a clear verb (returns) and object (incentive programs), and the qualifier "active and historical" scopes what is returned. It does not need to distinguish from a close sibling, since none of the listed tools returns incentive-program data (get_your_incentive_earnings is user-specific earnings, not program definitions), though it never says so.

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

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

The description offers no when-to-use guidance, no prerequisites, and no steering away from related tools such as get_your_incentive_earnings. An agent must infer from the name alone whether to call this for program catalogs versus personal earnings.

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

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

The annotations already establish that the operation is read-only, idempotent, non-destructive, and open-world, while the description confirms a single-resource retrieval. It adds no further context about missing slugs, not-found behavior, data freshness, or the returned league representation.

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 sentence is front-loaded, grammatical, and contains no filler. Its brevity is appropriate for a simple one-parameter lookup, with selection and behavioral omissions assessed separately.

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 schema and annotations provide nearly everything needed to invoke this simple read operation correctly. With no output schema, however, a brief result overview and not-found behavior would improve completeness, as would explicit routing from get_all_leagues for slug discovery.

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 required string parameter is already documented as “League slug,” so the baseline score applies. The description adds no slug syntax, example, case-sensitivity rule, or source for obtaining valid slugs.

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?

“Retrieve a league by its slug” clearly states the verb, resource, and lookup key. It implies a single-league lookup but does not explicitly distinguish the tool from siblings such as get_all_leagues or get_sport_by_slug.

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

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

The phrase “by its slug” implies that the tool is appropriate when the caller already knows a league slug. There is no explicit guidance on when to prefer get_all_leagues for discovery or get_events_by_league_slug for retrieving events.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety and idempotency are covered. The description adds that data is "current" (a snapshot, not historical) and lightweight, but says nothing about data freshness, staleness, or failure behavior for an unknown slug. Adds modest value beyond the structured hints.

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 front-loaded sentence with no filler; the resource and scoping key appear early. It is dense but every phrase (best bid/offer, stats, lightweight) 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, the description carries the burden of describing returns; it names the fields at a high level (best bid/offer, stats) but not their shape, units, or whether values can be null when no quotes exist. Adequate but leaves gaps for a data-retrieval tool.

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

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

Schema coverage is 100% and there is a single required parameter, so the schema already carries the burden. The description only restates that the slug identifies "a specific market", adding no format, casing, or lookup guidance 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 ("retrieve") and resource ("current market data (best bid/offer, stats)") scoped by market slug. It implicitly distinguishes itself from the full-book sibling by emphasizing a "lightweight format", but it never names get_market_book or get_market_by_slug, so 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?

"Lightweight format" hints at when to prefer this over a heavier book query, but there is no explicit when-to-use/when-not statement and no named alternative. An agent must deduce that this is the cheap snapshot versus get_market_book.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a small amount beyond that by naming the returned content (order book, stats) and saying data is 'current', but it does not say whether that means a live snapshot, how deep the book is, or how stale it can be.

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

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

A single front-loaded sentence with no filler; the resource and the lookup key both appear immediately. The parenthetical '(order book, stats)' is slightly informal but earns its place by naming the returned 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?

The tool is simple (one required param, annotations present, no output schema), and the description signals the general return content. It falls short on disambiguating from sibling read tools and on describing the shape of the market book, which the missing output schema leaves undocumented.

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 description coverage is 100%, so the schema already documents 'slug'. The description restates that lookup is by slug but adds no format or resolution detail (e.g. case sensitivity or where to obtain a slug) beyond the schema, matching the baseline 3.

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

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

Specific verb ('Retrieve') plus resource ('current market data (order book, stats)') plus an identifying key ('by its slug'). It is clear what the tool does, but it never distinguishes itself from close siblings like get_market_by_slug, get_market_bbo, or get_market_settlement, so the agent must guess which of these returns the book.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative named. The crowded sibling set (get_market_by_slug, get_market_by_id, get_market_bbo, get_market_settlement) makes a routing statement especially valuable, and none is present.

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, open-world behavior, so the safety profile is covered. The description adds nothing beyond that — no note on error behavior for unknown IDs, no return shape, no rate/scope 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?

One short sentence, front-loaded with the action and object, with no filler. It is concise but so terse that conciseness comes at the cost of 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?

For a lookup tool with no output schema, the description should at least hint at what a market object contains or distinguish ID-based lookup from slug-based lookup. As written, an agent must open the schema and guess among siblings to call it 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 100% with a single required integer parameter documented as "Market ID", so the schema does the work. The description adds no format, range, or sourcing detail beyond what is already structured.

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 verb and resource ("Retrieve a specific market"), but it essentially restates the tool name and title, which already say 'Get Market By Id'. It offers no differentiation from close siblings such as get_market_by_slug or get_markets, which is exactly where an agent needs help.

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

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

There is no guidance on when to use this versus get_market_by_slug, get_markets, or get_market_bbo. The description only implies usage through the word 'ID', leaving the agent to infer that a numeric ID (not a slug) is the selector.

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 fully covered elsewhere. The description adds nothing beyond that structure — no error behavior for missing slugs, no note on whether the response is a snapshot or live, and no hint about openWorld lookups returning empty results.

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

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

One short, front-loaded sentence with zero waste, which is appropriate for a single-parameter getter. It is efficient but leaves no room for the disambiguation an agent could use.

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

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

For a one-parameter read tool with full schema coverage and rich annotations, the description is just barely sufficient. It omits any statement of the resource's shape or what a market identifier represents, which matters because several sibling tools operate on the same entity type.

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 'slug' parameter is documented, so the baseline is 3. The description only restates that the lookup is by slug, adding no format, casing, or validity information 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?

A specific verb ('Retrieve') and resource ('market') keyed on an explicit lookup field ('slug'), so an agent knows what it returns. It does not, however, distinguish itself from the closely related sibling get_market_by_id or from the broader get_markets list tool.

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

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

No guidance on when to prefer this over get_market_by_id or get_markets; the agent must infer from the tool name that a slug lookup is required. No prerequisites, no mention of what to do when the slug is unknown, and no exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description contributes nothing beyond that: it says nothing about pagination defaults, result size, ordering behavior, or whether archived/closed markets are excluded by default (a real ambiguity given the active/closed/archived filters).

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

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

It is only four words, so there is no wasted phrasing, but the structure is under-specified rather than concise. A single front-loaded clause identifying it as a filterable, paginated market listing would cost one more sentence and add real value.

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

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

For a tool whose only parameter is a 24-field nested query object with no output schema, the description is too thin. It omits pagination semantics (limit/offset), default filtering behavior, and any hint of the return shape, all of which an agent needs to invoke it correctly.

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

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

Schema description coverage is 100% and the nested query object documents every field, so the description is not required to explain parameters. It adds no meaning beyond the schema, which is the expected baseline 3 case when the schema does the heavy lifting.

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

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

The description is close to a restatement of the name: "Retrieve all markets" says the verb and resource but adds nothing about scope, filtering, or the fact that this is a filtered list endpoint rather than a lookup. It does not distinguish itself from siblings like get_market_by_id or get_market_by_slug.

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 guidance and no mention of alternatives. An agent cannot tell from this text whether get_markets should be preferred over get_market_by_id/get_market_by_slug for a single lookup, or when a broad listing is appropriate.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is fully covered structurally. The description adds no behavior beyond that: it does not say what happens for an unresolved market, whether an error or empty result is returned, or the units/scale of the settlement price. For a lookup whose main ambiguity is settlement state, this 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?

One front-loaded sentence with no wasted words. It is arguably too terse for the ambiguity involved, but nothing is redundant or buried.

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

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

For a one-parameter read, the definition is minimally sufficient to invoke the tool. However, with no output schema and no explanation of the returned value's format or the unresolved-market case, an agent cannot predict the result shape from the description alone.

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 required slug parameter, so the schema already carries the parameter documentation and a baseline of 3 applies. The phrase "by its slug" restates the schema without adding format, case, or resolution-behavior detail.

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

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

The description states a specific verb and resource ("Retrieve the settlement price for a specific market") and names the keying parameter (slug). It is clear what the tool returns in concept, but it does not distinguish itself from close siblings such as get_market_by_slug, get_market_bbo, or get_price_history, which an agent could plausibly pick instead.

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 guidance and no mention of alternatives or prerequisites. The description does not say whether the market must already be resolved, nor why one would call this instead of get_market_by_slug or get_price_history.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is fully covered. The description adds only that results are scoped to the authenticated user's open orders — no details on pagination, result volume, or what 'open' means (unfilled vs partially filled).

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 short, front-loaded sentence with no filler. It is concise to the point of being thin, but nothing is wasted or buried.

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, yet the description says nothing about the shape of returned orders or pagination behavior, despite the schema exposing a pagination-bearing query object. For a listing endpoint this leaves an agent guessing about result size and how to page.

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

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

Schema description coverage is 100%, including the nested slugs filter, so the description need not repeat parameter syntax. It adds no parameter meaning, and notably never mentions that filtering by market slug is even possible, leaving an agent to discover it in 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 and resource (get open orders) plus scope (authenticated user). It does not distinguish itself from sibling get_order (single order lookup) or cancel_all_open_orders, so an agent must infer the difference from names 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?

No guidance on when to call this versus get_order for a specific order, or versus create_order/cancel_all_open_orders. The only implicit cue is 'authenticated user', which hints at an auth prerequisite but nothing else.

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, open-world behavior, so the safety profile is fully covered elsewhere. The description's one addition is that the key is exchange-assigned, which is genuinely useful, but it says nothing about behavior on a missing/cancelled order or about how much history is 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?

A single front-loaded sentence with zero filler; the lookup key is stated inline where the agent needs it. Nothing could be removed without losing 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 one-parameter read with rich annotations and a fully documented schema, the definition is nearly sufficient. The only real omission is what the response contains or what happens when the order is unknown, which is a minor gap for a simple lookup.

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 parameter is documented in the schema itself. The description's phrasing ("exchange-assigned ID") mirrors the schema text rather than adding new meaning such as format or example values, 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 ("Get details for a specific order") plus the lookup key (exchange-assigned ID). The word "specific" implicitly contrasts with the list-style sibling get_open_orders, but no sibling is named explicitly, so it stops short of a 5.

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

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

Usage is only implied: an agent can infer this is the tool to use when it already holds an order ID. There is no explicit statement of when to prefer it over get_open_orders, nor any guidance for the case where the ID is a client-side identifier rather than an exchange one.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered by structured data. The description nonetheless adds real behavioral context beyond those hints: a 20 requests/second/IP limit, a 30-second cache recommendation, refresh staggering across markets, and the caveat that custom ranges return stored observations that may be irregular or sub-minute. Return-shape caveats (bid-ask spread preserved, prices can sum above 1) are also 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?

Front-loaded with the purpose, then a bulleted profile table that is dense but scannable; the length is largely justified by seven enum values that each need a fidelity pairing. The closing caching/rate-limit sentence is operationally useful but adds bulk and a markdown link, which slightly dilutes the otherwise tight structure.

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 explain the returned fields itself — it does, defining `longPrice` and `shortPrice` and warning that they preserve the spread and are not trades. Combined with mode selection, rate limits, and the live-update alternative, nothing essential for a correct call is missing.

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

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

Schema coverage is 100%, so a 3 would be the baseline, but the description adds meaning the schema cannot: it maps each enum interval to the exact `fidelity` value (1, 5, 180), states that custom ranges require both Unix timestamps plus `fidelity=1`, and equates `symbol` with the market slug. That is substantive guidance on mutually exclusive parameter combinations rather than a restatement of field docs.

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

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

Opens with a specific verb and resource: "Returns book-derived Yes and No display prices for one market." It pins the scope (one market per request) and clarifies the semantics of the returned values (derived from best ask / one minus best bid, not individual trades), which separates it from the OHLC series sibling and from get_market_bbo.

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

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

Gives explicit when-to-use routing: enumerated fixed profiles with their required `fidelity` values, custom ranges for short windows "up to 24 hours," and a direct handoff to the Markets WebSocket "for live updates after loading history." An agent can pick the correct mode without 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that, such as pagination behavior, authentication needs, rate limits, or how filtering affects results.

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

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

The description is a single front-loaded sentence with no wasted wording. It is concise, though its brevity contributes to gaps in routing and behavioral guidance rather than delivering complete 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?

The schema and annotations are rich enough to support invocation: filters are fully described and the read-only, idempotent behavior is declared. However, the description does not help an agent choose this tool over nearby siblings or explain the return shape, leaving clear gaps for a complex nested-filter 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?

Schema description coverage is 100%, and the nested query object documents fields like limit, cursor, rfqId, quoteId, status, and user filters. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description states a clear verb and resource: returns quotes, filtered by query parameters. It does not differentiate this tool from related siblings such as get_rfqs or get_rfq_trades, so it falls short of a fully specific 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 use get_quotes versus alternatives like get_rfqs, get_rfq_trades, create_quote, or delete_quote. The phrase 'matching the query filters' implies filtering but does not state use cases, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no pagination behavior, no note that limit is capped at 100, no indication that userFilter only permits SELF, and no hint at result ordering or completeness.

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 zero filler. It is efficiently sized, though the terseness borders on under-specification rather than optimal economy.

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

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

For a read-only list tool with full annotation coverage and a fully described nested schema, the minimum is nearly met. Still missing is anything about pagination semantics (cursor + limit interplay) and result shape, which matter for a capped, paginated list endpoint.

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 nested query object itself documents 'Query parameters and pagination; use the exact field names shown.'. The description's phrase 'query filters' adds no meaning beyond the schema, so the baseline 3 applies.

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

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

The verb 'Returns' plus resource 'RFQs' makes the basic operation clear, and 'matching the query filters' indicates it is a filtered list. However, it gives no differentiation from close siblings such as get_rfq_user_id, get_rfq_trades, or get_quotes, so an agent must infer which RFQ-related read tool applies.

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 contains no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Nothing indicates whether it returns only the caller's RFQs (the schema's userFilter enum suggests USER_FILTER_SELF) or others'.

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 the result ordering (newest first), anonymity of the fills, eventual visibility of history, the existence of late-arriving records requiring overlapping windows, a dedupe key (tradeId), and that later corrections and busts do not amend these prints. These are exactly the non-obvious traits an agent needs to consume the data correctly and cannot be inferred from readOnly/idempotent hints.

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?

Sentences are short, front-loaded with the core 'what' before pagination and consistency caveats. Every clause carries information; nothing is filler or restatement of the title.

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 paginated read tool with full schema coverage, complete annotations, and no output schema, the description covers what is returned, ordering, anonymity, pagination lifecycle, and data-consistency caveats (late arrivals, dedupe, busts). An agent has everything needed to call it and interpret the results without further inference.

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 a baseline of 3 applies, and the description adds a genuinely new rule the schema lacks: an empty cursor terminates the traversal. The instruction to repeat identical filters and limit with each cursor reinforces the schema's opaque-continuation note and clarifies that cursor state is bound to the filter set. It does not add anything about startTime/endTime semantics that the schema doesn't already carry.

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 verb 'Returns' pairs with a precisely scoped resource: anonymous original fills where either order originated from an RFQ, newest first, including single instruments, combos, and later fills on resting orders. That is far more specific than the tool name alone. It stops short of naming a sibling (e.g. get_activities, get_quotes) to contrast against, so an agent must infer the boundary rather than being routed.

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?

Strong operational guidance is present: reuse the same filters and limit with each cursor, stop on an empty cursor, and requery overlapping time windows to catch late arrivals. However, none of this addresses when to choose this tool over alternatives such as get_quotes or get_activities; the selection guidance is only implied by the 'RFQ origin' scoping.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds one genuinely new behavioral fact: the call is scoped to the authenticated participant, implying an auth requirement and that the value is identity-derived rather than an input. It says nothing about failure modes when unauthenticated or whether an RFQ account must exist first.

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 well-formed sentence with the key qualifier ('public', 'authenticated participant') front-loaded and no wasted wording. It is arguably too terse for the value it could add, but nothing is 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 zero-parameter read-only getter with no output schema, the description is adequate but leaves open what the returned ID is used for and whether it is stable across sessions. A brief note on where this ID feeds into the RFQ/quote workflow would make it 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 and the schema is fully described, so there is nothing for the description to clarify beyond confirming the no-argument nature of the call. Baseline 4 applies.

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

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

The description uses a specific verb ('Returns') and a precisely named resource ('the public RFQ user ID'), scoped to 'the authenticated participant'. An agent can distinguish it from siblings like get_rfqs or get_quotes, though it never explicitly contrasts itself with them.

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

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

There is no guidance on when this tool should be called, what it is a prerequisite for (e.g., identifying oneself when creating or reading RFQs), or any conditions/exclusions. Usage is only inferable from the name and the 'authenticated participant' phrasing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not explain pagination defaults, result ordering, whether inactive series are returned by default, or any rate/volume characteristics of an 'all' retrieval.

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 words are technically terse but wildly under-specified for a tool whose single parameter is a nested object with roughly twenty sub-fields including duplicate params.* aliases. This is not conciseness but omission; no sentence earns its place because the one present sentence carries no operational 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 nested-object listing tool with duplicate/aliased parameter paths and no output schema, the description should at minimum clarify filtering versus full retrieval and the expected return shape. Annotations cover the read-only profile, but the description leaves the caller without enough to invoke it confidently.

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 reported at 100% and the query object's fields carry descriptions, so the schema does the heavy lifting and a baseline of 3 applies. The description contributes no additional meaning, and it arguably misleads by calling this 'all series' when the schema supports slug, active, recurrence and category filters.

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 verb and resource ("Retrieve all series"), which is enough to know it reads series data, but it gives no scope detail and does nothing to distinguish it from sibling tools like get_series_by_id or get_tags. An agent cannot tell from this text whether pagination, filtering, or the active-flag semantics apply.

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 guidance at all: no mention of when to pick this over get_series_by_id, no note that the 'all' framing is misleading because the schema exposes slug, active, and recurrence filters, and no prerequisites. The agent must infer usage entirely from the schema.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds nothing beyond that — no mention of behavior when the ID is unknown, no indication of what a 'series' object contains, and no note on data freshness given the open-world hint.

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 short sentence, front-loaded with the verb and free of padding. It is terse to the point of under-specification, but no wording is wasted.

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

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

For a one-parameter lookup, the description plus schema plus annotations cover enough to invoke the tool correctly. However, with no output schema, the description should say something about the returned object or the not-found case, which it does not.

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

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

Schema description coverage is 100% with a single required integer 'id', so the schema carries the parameter documentation. The description's 'by its ID' merely restates the schema without adding format, range, or source-of-ID guidance.

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

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

States a specific verb ('Retrieve') and resource ('a specific series') with the lookup key ('by its ID'), which implicitly separates it from the sibling list tool get_series. It does not explicitly name the sibling, so the differentiation is inferable rather than stated.

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

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

There is no guidance on when to use this versus get_series or the various get_event_by_id/get_market_by_id siblings. The only implied usage is 'when you already have an ID,' which the agent must infer.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds one useful behavioral fact beyond that: the response embeds all leagues for the sport. It does not disclose what happens on an unknown slug (error vs empty result) or whether the lookup is cached.

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 short sentence with zero filler, and the key information (slug lookup plus attached leagues) is front-loaded. Nothing could be removed without losing meaning.

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

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

For a one-parameter read-only lookup with full schema coverage this is close to sufficient, and the description usefully states that leagues are attached to the result, partly compensating for the missing output schema. A little more on the returned sport fields or not-found behavior would make it complete.

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

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

Schema description coverage is 100% and the single parameter is documented as "Sport slug", so the schema already does the work. The description only restates that the lookup keys on a slug, adding no format, casing, or disambiguation details. 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 ("Retrieve") and resource ("a sport by its slug") and adds the payload shape ("with all leagues attached"). It does not distinguish itself from near-duplicate siblings such as get_sports or get_all_sports, so an agent must infer that this is the single-item slug lookup.

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 contains no when-to-use guidance and names no alternative, which matters here because the sibling list contains get_sports, get_all_sports, get_league_by_slug and get_events_by_sport_slug. The only implicit signal is that a slug is required, leaving the agent to infer when a slug lookup beats a listing call.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that, however: no note on the return set (all sports vs. a subset), no ordering, no sense of how large the payload is, and no indication of how it differs from get_all_sports.

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 words are technically waste-free, but for a tool that sits in a dense cluster of near-identical siblings this is under-specification rather than conciseness. The single phrase is front-loaded yet carries almost no 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 parameters and no output schema, the description is the only place to explain what is returned and how it relates to get_all_sports and get_sports_events. It does neither, leaving the agent with an unresolved ambiguity in a crowded namespace.

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 with full schema coverage, so there is no parameter meaning for the description to carry. Baseline 4 applies; nothing here is misleading.

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?

"Fetch sports data" only restates the tool name in slightly different words; it never says what a "sport" object is or what this returns. Crucially, siblings include get_all_sports, get_sport_by_slug, get_sports_events, get_sports_teams and get_sports_players, and the description gives no basis for choosing this tool over get_all_sports, which appears to cover the same resource.

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 exclusion, and no mention of any alternative among the many sports-related siblings. An agent has to guess whether this is a list-all endpoint or something narrower than get_all_sports.

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, openWorld), so the description's burden is lighter, but it adds almost nothing beyond them. 'Same structure as home page' references an undefined baseline and does not disclose pagination behavior, response shape, or what 'trending' vs 'live' actually changes in the result.

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 a single short sentence, which is appropriately sized and front-loaded with the verb and resource. However, the trailing clause 'Same structure as home page' is unresolvable filler that consumes attention without conveying usable information.

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

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

With no output schema, the description is the only place an agent could learn what comes back, and the vague 'same structure as home page' does not deliver that. The input side is fully covered by a rich nested schema, which keeps this from being inadequate, but the return-side gap is real given the tool's openWorld read nature.

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

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

Schema description coverage is 100%, so the schema already documents seriesId, type, limit, offset, section, and excludeEventId, making 3 the baseline. The description gestures at 'trending/live/sport section' but does not map these terms to the `section` and `type` fields or clarify the interaction between them, so it adds little beyond the schema.

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

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

The description states a verb and resource ('Retrieve events sections for a sport series'), which is clear enough at a high level, but 'sections' and 'same structure as home page' are undefined, and nothing distinguishes this from sibling tools like get_events or get_events_by_sport_slug. An agent still has to guess whether this returns events, markets, or layout blocks.

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 is given, and no alternative is named despite get_events, get_events_by_sport_slug, and get_series_by_id appearing in the sibling list. The parenthetical '(optional trending, optional live, and sport section)' hints at available modes but does not explain when an agent should prefer one over the other.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds no behavior beyond that: it says nothing about pagination defaults, result ordering, or the conditional constraints (league only honored with a provider filter, providerPlayerId requires provider) that live only in the schema.

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

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

A single front-loaded sentence with no filler; the resource is stated first and the filters follow. Minor imprecision in calling the provider-player-id pair 'provider reference' rather than matching the schema field names 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?

For a read-only nested-query lookup tool with no output schema and full schema description coverage, the definition is sufficient to call it correctly; the conditional filter rules are documented in the schema itself. Only the absence of any routing guidance against the many sibling lookup tools leaves a real gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description enumerates the same filter dimensions the schema already documents and adds no extra meaning, such as clarifying that 'provider reference' maps to the provider/providerPlayerId pair or explaining the limit/offset pagination model.

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 ('Fetch') and resource ('sports players'), and the filter list clarifies the lookup dimensions. It is clearly distinguishable from siblings such as get_sports_teams and get_sports_events by resource alone, though it never names an alternative explicitly.

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

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

There is no when-to-use guidance, no exclusion conditions, and no mention of when to prefer get_sports_teams or provider-specific siblings. The listed filters weakly imply lookup scenarios but nothing tells the agent which tool to pick for a given task.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds nothing further – no default page size, no behavior when filters are omitted, no note that an empty query returns an unfiltered set. 'For enriching sports events' is usage framing, not behavioral disclosure.

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

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

It is a single short sentence with no redundancy, which is good, but the one clause it does contain ('for enriching sports events') is vague filler that does not help invocation. Brevity here comes at the cost of substance rather than from efficiency.

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 schema is fully described and there is no output schema to compensate for, so the description need not explain return values. For a simple read-only list tool with a fully annotated nested query, the description's main gap is sibling routing rather than call mechanics.

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

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

The single parameter is a nested query object whose fields are documented at 100% coverage in the schema, including limit, offset, orderBy, and filters. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('Fetch sports teams data'), so the basic operation is identifiable. However, the trailing rationale 'for enriching sports events' muddies rather than clarifies scope, and nothing distinguishes this from close siblings like get_sports_teams_for_provider or get_sports_players.

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 guidance, no exclusions, and no mention of the sibling tools that also return team-like data. The agent must infer from the name alone which of several team/sport retrieval tools to pick.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety behavior is covered. The description adds almost no behavioral context beyond restating that this is a fetch operation; it does not mention provider-specific constraints, rate limits, pagination behavior, or what happens when no provider is supplied.

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

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

The definition is a single front-loaded sentence with no wasted words. It is appropriately concise, though its brevity leaves important sibling differentiation and usage context unstated.

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 relatively simple and the annotations plus schema cover most operational details. However, the description does not resolve the ambiguity with the sibling get_sports_teams or clarify that the provider parameter is optional in the schema despite the 'specific provider' phrasing.

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

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

Schema description coverage is 100%, so the nested query object's league, teamIds, and provider fields are already documented in the schema. The description only reiterates the provider scope and adds no extra meaning about the league or teamIds filters, 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?

The description states a specific verb ('Fetch') and resource ('sports teams data') plus a scope ('for a specific provider'). It is understandable on its own, though it does not explicitly distinguish this tool from the sibling get_sports_teams beyond the name-level qualifier.

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

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

The description gives no explicit guidance on when to use this tool versus get_sports_teams, get_all_sports, or other sports-related siblings. The phrase 'for a specific provider' implies provider-scoped usage, but no alternatives, exclusions, or prerequisites are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so safety is fully covered structurally. The description adds nothing beyond them — no note on what a tag object looks like, that a missing ID yields an error, or that openWorld data may evolve. With annotations covering the baseline, the description still fails to contribute any behavioral context of its own.

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 short sentence, front-loaded, with no filler or redundancy. It is efficient but its brevity stems from under-specification rather than disciplined editing.

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

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

This is a simple single-parameter lookup with full annotation coverage and no output schema, so little needs to be said. However, an agent still cannot tell from the description whether the returned tag is the same shape as those from get_tags, nor is there any routing hint against get_tag_by_slug, leaving a real informational 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 `id` parameter is documented as "Tag ID to retrieve", so the schema carries parameter meaning entirely. The description adds no format, range, or error semantics beyond that, which lands at the baseline for full 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?

"Get a tag by its ID" restates the name and title almost verbatim; the only added information is that lookup is by ID, which a reader already infers from the name and the single required `id` parameter. It gives no basis for choosing between this and the closely related siblings get_tag_by_slug, get_tags, or get_events_for_a_tag.

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 guidance at all. The sibling list contains three plausible alternatives (get_tags for listing, get_tag_by_slug for slug lookup, get_events_for_a_tag for associations), and the description never states the condition that selects this one over 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that - no note on not-found behavior, no indication of what a tag record contains, and no mention of the open-world lookup implied by the slug key.

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 a single, front-loaded sentence with zero padding. The brevity is structurally clean, though it reflects under-specification rather than disciplined economy.

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

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

For a one-parameter lookup with full schema coverage, complete annotations, and no output schema, the minimum needed to invoke the tool is present. What is missing is disambiguation from get_tag_by_id and any statement of return content or failure behavior, which an agent would still have to guess.

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 a single parameter and schema description coverage is 100%, with the schema stating "Tag slug to retrieve." Per the baseline, that alone supports a 3; the description contributes no additional detail such as slug casing or format expectations.

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 verbatim restatement of the tool name and title: "Get a tag by its slug." It gives no context about what a tag is or how it relates to the sibling get_tag_by_id, so the only differentiation available to an agent is the name itself.

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 lookup versus the closely related get_tag_by_id or get_tags, nor any note about slug format or what happens when a slug does not exist. Usage must be inferred 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 readOnlyHint, idempotentHint, non-destructive and open-world, so the safety profile is covered. The description's one genuine addition is 'ranked', which discloses that results come back in a relevance/rank order rather than arbitrary order. It says nothing about what ranking is based on, default page size, or total-count behavior, so the added context is real but thin.

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 short sentence with no redundant clauses, and the core action ('Get ranked tags') is front-loaded before the qualifier. It is efficient and readable. It stops short of a 5 because the brevity edges into under-specification rather than disciplined economy — nothing about ordering defaults or result shape is established.

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 exposes a single nested object with nine documented fields, and the schema plus annotations together cover parameter meaning and safety, which lowers the description's burden. Still, for a ranked listing tool with no output schema, the description gives no sense of what a returned tag looks like or how ranking/pagination defaults behave. Adequate but with clear gaps relative to the parameter richness.

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 every field inside the nested query object (ids, slug, limit, offset, query, orderBy, orderDirection, parentId, parentSlug) is documented in the schema itself, including the parentId/parentSlug precedence rule. The description adds no meaning beyond that, so the baseline of 3 applies. The phrase 'optional filtering' at least confirms all filters are optional, matching required-parameters=0.

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 ('Get ranked tags') plus a scope qualifier ('with optional filtering'), so the action is intelligible. However, it never distinguishes itself from the closely named siblings get_tag_by_id and get_tag_by_slug, nor does it clarify whether this returns the full tag catalog versus a filtered subset. An agent must infer that this is the list/search 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?

There is no when-to-use guidance and no named alternative. Given that get_tag_by_id, get_tag_by_slug, and get_events_for_a_tag all sit in the same namespace, the description should route the agent (e.g. 'use when you need to search/browse tags rather than fetch one by identifier'), but it does not. Usage is only weakly implied by the word 'filtering'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the all-markets-vs-single-market scoping and says nothing extra about authentication requirements, result ordering, or behavior when no positions exist. Adequate but not additive.

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 scope qualifier arrives before any other information. Slight redundancy in 'across all markets or filtered by specific market', which could be tightened, 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?

For a simple read tool with full schema coverage, rich annotations and no output schema, the description is minimally sufficient. It omits two things an agent would benefit from knowing: that positions belong to the authenticated user, and that results are paginated via cursor/limit.

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%, with limit, cursor and market all documented inline including examples and pagination semantics, so the baseline is 3. The description's mention of 'filtered by specific market' merely restates the market parameter without adding format or edge-case 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 ('Get') and resource ('user's trading positions') plus the scope ('across all markets or filtered by specific market'). An agent can distinguish it from the trading mutation siblings like close_position_order or create_order. It falls short of 5 only because it doesn't name a closely related alternative 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 implies two usage modes — retrieve everything, or narrow to one market — which is reasonable implicit guidance. However it gives no explicit when-to-use/when-not guidance, no mention of the sibling close_position_order for exiting a position, and no statement that this returns the authenticated account's positions (there is no user parameter in the schema).

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful behavior: results are pre-aggregated per (market, date) pair and dates are in Eastern Time. It says nothing about pagination, result caps, or what an entry contains, which matters since the schema's query object mentions pagination but exposes no pagination 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?

Two sentences, zero waste, and the core purpose plus the non-obvious aggregation/timezone semantics are front-loaded. Nothing redundant with the title.

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 does some of that work by explaining the entry grain and timezone. But it omits pagination behavior, any indication of entry fields, and the distinction from the incentive-programs tool, leaving real gaps for a read tool whose return shape is otherwise undefined.

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

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

Schema description coverage is 100%, so all four nested query fields (start_date, end_date, market_slug, program_type) are documented with formats and defaults. The description adds only the Eastern Time framing, which applies to result grouping rather than clarifying the input filters. Baseline 3 is appropriate when the schema carries the load.

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 rewards earned by the authenticated caller, plus the aggregation grain (one entry per market/date pair). An agent can distinguish this from get_incentive_programs, which lists program definitions rather than the caller's payouts, though the description never names that 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?

Usage is implied by 'authenticated caller' — this is the per-user earnings view — but there is no explicit when-to-use, when-not-to-use, or routing to an alternative such as get_incentive_programs for program metadata. The agent must infer the boundary.

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

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

Goes well beyond the annotations: it discloses cancel-replace semantics, all-or-nothing gateway validation, that unknown orderIds may be silently ignored by the exchange, and that modifiedOrderIds is an echo rather than an execution confirmation. These are exactly the failure modes an agent needs for a destructive, non-idempotent live-trading call.

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 risk warning is correctly front-loaded, but the final sentence ("Returned IDs may not confirm exchange execution; verify the outcome") restates the earlier modifiedOrderIds-is-an-echo sentence, and "may affect real funds" duplicates the LIVE ACCOUNT ACTION header. Two sentences of the six are 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 destructive live-trading tool with a deeply nested schema and no output schema, it covers atomicity, silent-ignore behavior, and result-verification caveats. It stops short of noting whether exchange-side per-entry failures can yield partial success or what permissions/rate limits apply.

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 nested body/orders shape is fully documented in the schema, so the baseline is 3. The description adds only the batch cardinality (already encoded as minItems/maxItems) and the per-entry cancel-replace meaning; it adds no field-level guidance such as which fields are optional or what happens to omitted fields.

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 with scope: "Modify up to 20 existing orders in a single request." The batch limit and the cancel-replace forwarding rule distinguish it from the singular modify_order and from create_multiple_orders without needing to open 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?

The "LIVE ACCOUNT ACTION" prefix and the 20-order cap make the intended context clear: real-money batch modification. It never explicitly routes the agent away from this tool (e.g., "use modify_order for a single order" or "use cancel_multiple_orders to only cancel"), so there are no stated exclusions.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is largely covered. The description reinforces this with 'may affect real funds or account state', but omits operationally relevant behavior such as whether unspecified fields are preserved, whether the order loses queue priority, or how failures are surfaced.

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

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

Three short sentences, front-loaded with the highest-value warning ('LIVE ACCOUNT ACTION') and the core purpose. The closing 'may affect real funds' slightly duplicates that warning but is not wasteful enough to penalize heavily.

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 destructive mutation with a nested body object and no output schema, the description should say what the call returns (e.g., the revised order) and whether the change is reversible. Those gaps are material, though the annotations and rich schema partly compensate.

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

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

Schema description coverage is 100%, so the schema already documents every field including the nested price object, enum values for tif, and quantity decimals. The description only recaps three fields and adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

The description uses a specific verb and resource ('Modify an existing order in the marketplace') and enumerates changeable fields (price, quantity, time in force). It does not distinguish this from the sibling modify_multiple_orders, which an agent must disambiguate on its own.

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

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

Usage is implied by 'modify an existing order' and the 'LIVE ACCOUNT ACTION' prefix signals real-money impact, but there is no explicit when-to-use/when-not guidance and no mention of the single-vs-bulk alternative (modify_multiple_orders) or when to cancel and re-create instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the call yields expected fills and parameter validation, but does not say whether a preview reserves funds, consumes rate limit, or how validation failures are surfaced.

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 purpose and the two things the caller gets back are stated immediately.

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

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

For a complex nested order payload with no output schema, the description should say more about what a preview returns (validation errors? fill simulation? fee estimate?) and whether it is side-effect free. It hints at returns ("expected fills") but leaves the response shape and failure modes to inference.

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 nested order body documents every field (intent vs. outcomeSide+action, price required for limit orders, cashOrderQty for market orders). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

The description gives a specific verb+resource ("Preview an order") and adds scope: it happens "before submission" and returns validation results plus expected fills. It is clearly distinguishable from create_order, though it never names that 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?

"before submission to validate parameters" establishes a clear usage context and ordering relative to actually placing an order. It lacks an explicit exclusion (e.g., "does not place the order; use create_order for that") or prerequisites such as authentication or balance checks.

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, openWorld, non-destructive, so the safety profile is covered and the bar is lower. However, the description adds nothing behavioral: it doesn't indicate what corpus is searched, how results are ordered, or that pagination exists. OpenWorld suggests non-exhaustive external results, which the description never reinforces.

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 sentence is short with no filler, but its brevity comes from under-specification rather than efficient communication. Nothing is front-loaded because there is essentially nothing to front-load.

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 nested-filter, open-world search tool with no output schema and many competing siblings, the description omits everything an agent needs: what entities are searched, result shape, and ordering. Annotations only 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% and the nested query object documents every filter (status, seriesIds, marketType, time bounds, comboEnabledOnly). The description adds no meaning beyond that, but per the high-coverage baseline a 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?

"Search for a given query" merely restates the tool name and the obvious parameter. It never says what resource is being searched (events, markets, series, tags?) in an API whose siblings include many concrete retrieval tools, so an agent cannot distinguish this from get_events, get_markets, or get_series.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. With roughly 50 sibling retrieval tools, the absence of any statement like "use this for free-text matching across entities instead of the typed get_* endpoints" leaves selection to guesswork.

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