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

With no annotations, the description carries the full burden and does well: it discloses the side effect (remaining assets returned to the owner) and the return contract (unsigned transaction CBOR to be signed by the wallet), which tells the agent a follow-up signing step is required. It stops short of stating authorization requirements or whether cancellation 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?

Three short sentences with zero filler; the action, its effect, and its return value are front-loaded in that order. Every sentence earns its place.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers the essential unknowns: what it does, the asset-return side effect, and the CBOR return value. Only auth/permission context and error behavior are missing, which is a minor gap at this complexity level.

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

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

Schema description coverage is 100%, so both parameters (orderId format '{txHash}#{outputIndex}' and bech32 walletAddress) are fully documented in the schema. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb (Cancel) and resource (an active DCA order), and the resource noun cleanly distinguishes it from siblings like cancel_otc_offer or create_dca_order. An agent can route to it without opening any schema.

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

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

The qualifier 'active' implies the order must be live, which is useful implied context. But there is no explicit when-to-use guidance, no mention of how to obtain a valid orderId (e.g., get_dca_orders), and no statement of preconditions or alternatives.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the result is an unsigned transaction CBOR requiring the seller's wallet signature, which reveals a two-step flow rather than a completed cancellation. It still omits auth/permission requirements, whether the cancellation is reversible, and any timing or fee behavior.

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

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

Two tight sentences with no waste; the action is front-loaded and the return-value note follows naturally. Every sentence earns its place.

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

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

For a 2-parameter tool with no output schema, the description covers the core action and the return artifact (unsigned CBOR), which is what an agent needs to chain a signing step. It lacks prerequisites and failure/edge behavior, but is nearly complete given the schema 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%: both offerId and walletAddress are documented with format and role in the schema itself. The description adds no meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb (Cancel) and resource (OTC offer), which distinguishes it cleanly from the create/fill/query OTC siblings. However, it does not explicitly name alternatives or scope conditions, so it stops short of full sibling differentiation.

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

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

The description says what the tool does but never states when to use it, when not to, or which sibling to prefer (e.g., vs. get_otc_offer_by_id to verify an offer exists first). No prerequisites or contextual routing is provided.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the return behavior ('Returns an unsigned transaction CBOR to be signed by the wallet'), implicating a build-then-sign workflow rather than immediate submission. However, it omits authorization requirements, whether the order is registered before signing, and what the agent must do next.

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 filler. The purpose is front-loaded and the return-value note follows. Every sentence earns its place.

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

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

With 11 params, no annotations, and no output schema, the description covers the core purpose and the return type but leaves the surrounding workflow (signing/submission step, order lifecycle) unexplained. Adequate but with clear gaps for a transaction-building 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%, so all 11 parameters (including nested maxPrice/minPrice objects and defaults) are already documented in the schema. 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 gives a specific verb ('Create') and resource ('Dollar Cost Averaging (DCA) order'), expands the acronym, and clarifies the nature of the operation ('automated recurring swaps at specified intervals'). This clearly distinguishes it from read siblings (get_dca_orders, get_all_dca_orders) and the destructive sibling (cancel_dca_order) without needing to name them.

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

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

The phrase 'automated recurring swaps at specified intervals' implies the use case (recurring buys vs. one-time swaps), but there is no explicit when-to-use guidance, no mention of alternatives like submit_swap or swap_aggregate, and no prerequisites. Usage is only inferable from the described behavior.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully notes the return is an 'unsigned transaction CBOR and offer ID,' implying the caller must sign/broadcast, but it never states whether the offer goes live immediately, what permissions are needed, or what the signing/submission step entails. Partial disclosure for a mutation tool with zero annotation coverage.

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

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

Two tight sentences with zero waste, front-loading the core action and then the return contract. Every sentence earns its place and nothing is 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?

With no output schema the description does cover the return value (CBOR + offer ID), which is helpful. However, for an 8-parameter nested-object mutation tool with no annotations, it omits the post-creation workflow (signing/broadcasting), auth requirements, and lifecycle details, leaving meaningful gaps.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters including the nested asset objects and fields like allowPartial/minTakeAmount. The description adds no parameter-level detail 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 peer-to-peer OTC trading offer on the Cardexscan marketplace.' The verb 'Create' inherently separates it from siblings like fill_otc_offer, cancel_otc_offer, and get_otc_offers, though no sibling is named explicitly. Purpose is unambiguous but lacks explicit routing language.

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 (e.g., wallet/signing), and never contrasts this with related siblings such as fill_otc_offer or submit_swap. The only usage signal is the implicit 'create an offer' reading of the name, which 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?

With no annotations, the description carries the full behavioral burden. It does add real value by disclosing the return artifact (unsigned CBOR) and that the buyer's wallet must sign it, which tells the agent this is not a completed mutation. It omits irreversibility, whether the offer is consumed/locked, and any auth requirements.

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

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

Two short sentences, zero padding, with the action stated first and the return contract second. Every clause earns its place.

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

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

With no output schema, the description correctly compensates by naming the return type (unsigned transaction CBOR) and the required follow-up signing step. What remains missing is error/precondition context — what happens if the offer is expired, already filled, or the buyer lacks funds.

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 offerId and walletAddress are already fully documented in the schema, including the bech32/addr1 format detail. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the work.

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?

"Accept and fill an existing OTC offer" gives a specific verb pair and resource, clearly distinct from create_otc_offer, cancel_otc_offer, and get_otc_offers. It doesn't explicitly name those siblings, but the action is unambiguous 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?

The phrase "an existing OTC offer" implies the precondition that the offer must already exist, and the return description implies this is a step in a sign-and-submit flow. However, it never states when to prefer this over swap_build_cbor or submit_swap, nor any prerequisites like buyer funding or offer validity.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only price lookup via 'current price', but never states the data source, freshness/staleness, latency, rate limits, or whether any auth is required. For a zero-annotation tool this is 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 front-loaded sentence with no filler. Every part ('current', 'ADA', 'USD') earns its place.

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

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

For a trivial zero-param lookup this is nearly sufficient, but with no output schema the description should say what the response looks like (a number, a timestamped price object, etc.). It leaves the return shape unspecified.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter meaning is missing.

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?

Clear specific verb (Get) plus resource (current price of ADA) with the unit clarified as USD and ADA identified as Cardano's native cryptocurrency. It is distinguishable from the DEX/trading siblings, though it does not explicitly contrast itself with any of them.

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

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

The description states what the tool returns but gives no guidance on when to use it versus alternatives, no prerequisites, and no exclusions. Nothing tells an agent when this price lookup is the right choice over the token/pool 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses only that results are filtered to currently active orders; it says nothing about authentication requirements, pagination or result limits, rate limiting, or whether this is a public read.

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

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

The scope constraint is front-loaded, which is good, but the second sentence ('Returns all currently active DCA orders on the platform') restates the first with no new information. For a one-line tool, half the text 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?

With no output schema and no annotations, the description is the only source of return-shape information, and it omits pagination, ordering, and result-size behavior. For a simple zero-parameter list tool this is minimally adequate but leaves real gaps.

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

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

The tool takes zero parameters, so there is no parameter semantics to convey and the baseline of 4 applies. The description introduces no spurious or misleading parameter claims.

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

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

States a specific verb and resource ('Get all active DCA orders') plus the scope qualifier 'system-wide across all wallets', which implicitly separates it from get_dca_orders and get_wallet_orders. It does not name the sibling alternative explicitly, so sibling differentiation is inferred from scope wording 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?

Usage is only implied by the scope phrase 'system-wide across all wallets' — an agent can infer this is the platform-wide view rather than the per-wallet one. There is no explicit when-to-use/when-not guidance or named alternative for the wallet-scoped case.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return payload (status, amounts, execution progress), which is valuable given there is no output schema, but it says nothing about authorization needs, pagination, empty-result behavior, or whether the call is read-only.

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

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

Two compact sentences: the first states scope and the second states the return contents. Every clause carries information and the core action is front-loaded.

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

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

For a simple single-parameter read tool with full schema coverage, the description is nearly sufficient: it covers what is fetched and what comes back, compensating for the absent output schema. The remaining gap is that it does not disambiguate itself from the other DCA/order-listing 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?

Schema description coverage is 100% and the single parameter is fully documented in the schema (bech32, 'addr1' prefix), so baseline is 3. The description only restates that the address identifies a wallet, adding no format or constraint detail 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?

Specific verb+resource ('Get all DCA orders') scoped to one wallet address, and it names the return contents. It does not explicitly distinguish itself from close siblings like get_all_dca_orders or get_wallet_orders, so an agent must infer the scope difference from the parameter name.

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

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

The phrase 'for a specific Cardano wallet address' implies the usage context (per-wallet lookup), but there is no explicit when-to-use, no exclusions, and no reference to sibling tools such as get_all_dca_orders or get_pending_orders. Guidance is only implied.

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

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

No annotations are provided, so the description carries the full burden and does disclose the return payload (token names, amounts, prices, DEX names, timestamps), which is genuinely useful. It says nothing about pagination, result caps, rate limits, or whether the 'recent' window interacts with timezone, so the behavioral picture is incomplete for a zero-annotation tool.

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

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

Two tight sentences: the first defines the data source and scope, the second enumerates the return fields. No filler, and the essential scoping information is front-loaded.

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

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

For a one-parameter read tool with full schema coverage and no output schema, the description adequately covers purpose and return contents. The notable gap is sibling disambiguation against get_historical_trades and get_token_trades, which the agent needs in order to select 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%: the single 'timeframe' parameter is fully documented in the schema with its allowed values and default. The description adds no timeframe syntax beyond the vague word 'recent', so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get recent global trade data') plus the scope ('across all Cardano DEXes'), and even enumerates the returned fields. It implicitly differentiates from siblings like get_historical_trades ('recent' vs historical) and get_token_trades ('global' vs token-specific), but it never names those tools, so the differentiation is left to inference.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no alternatives are named, despite three sibling tools (get_historical_trades, get_token_trades) that clearly overlap in intent. The word 'recent' implies a time-bounded read, but the agent must guess which trade tool 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?

No annotations are provided, so the description carries the full disclosure burden. It says 'all historical trades' but does not address pagination, result caps, authentication, or what the response contains — all relevant for wallet history that could be very large.

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 efficient sentence with the scope front-loaded and no filler. Nothing is wasted, though there is also very little content for the length to earn credit against.

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 parameter and no annotations or output schema, the definition is minimally sufficient, but it omits pagination behavior and return shape for what could be an unbounded history query.

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 explains the bech32 'addr1' format, so the schema does the heavy lifting. The description adds only that the address is a 'Cardano wallet address', which rephrases rather than extends the schema.

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

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

States a specific verb ('Get') and resource ('historical trades') scoped to a wallet address. It implicitly separates itself from get_global_trades and get_token_trades via the 'specific Cardano wallet address' scope, but it never names those siblings to make the distinction 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 can infer this is for a wallet's own trade history, but the description gives no when-to-use framing, no exclusions, and no pointer to get_global_trades or get_token_trades for the non-wallet 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?

No annotations are provided, so the description carries the full behavioral burden. It does not say whether filled/cancelled/expired offers are included, whether results are paginated or sorted, or what the response shape looks like — significant gaps for a read tool with zero annotation coverage.

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

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

A single efficient sentence with the scope constraint front-loaded and no wasted words.

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

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

For a one-parameter read tool with no output schema, the description covers the essential purpose but omits filtering scope (active vs. historical offers), pagination, and its relationship to the broader OTC offer listing tool, which an agent would need to select 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%, so the single walletAddress parameter is already fully documented with its bech32 'addr1' format in the schema. The description only restates that the address identifies the offer creator, adding marginal semantic value.

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 all OTC offers') plus the scope ('created by a specific wallet address'), so the action is unambiguous. However, it does not differentiate itself from the sibling get_otc_offers (which presumably lists all offers) despite the name's 'my' framing, leaving the walletAddress-vs-authenticated-user distinction unexplained.

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 over get_otc_offers or get_otc_offer_by_id, and no mention of prerequisites such as needing a valid wallet address. The agent must infer usage entirely from the name.

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

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

With no annotations provided, the description carries the full behavioral burden. It does not state that this is a read-only operation, whether authentication is required, or what happens if the offer ID does not exist (e.g., error vs. null). For an unannotated tool this is a notable 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?

A single front-loaded sentence with no wasted words. It is efficient, though spare enough that it borders on under-specification rather than model conciseness.

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?

No output schema exists, so the description should explain what 'details' are returned; instead it leaves the return shape entirely unspecified. Combined with the absence of annotations and any failure-mode description, it is incomplete for an agent to call 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 100% with a single required 'offerId' whose description already documents it as 'the unique identifier of the OTC offer'. The description adds no format or sourcing detail 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 description states a specific verb ('Get') and resource ('OTC offer') scoped to a single item via 'by its ID'. This clearly distinguishes it from the list-style siblings like get_otc_offers and get_my_otc_offers, though it doesn't name 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 explicit guidance on when to use this versus get_otc_offers or get_my_otc_offers. The phrase 'by its ID' implies you need an identifier in hand, but no prerequisites (where the ID comes from) or alternatives are stated.

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

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

No annotations exist, so the description carries the full burden. It discloses what is returned (token details, prices, status), which is useful, but says nothing about pagination behavior despite page/pageSize params, nor about auth requirements or rate limits. Partial disclosure only.

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 tightly written sentences with the resource and scope front-loaded; no filler and every clause carries information about what the tool returns.

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 list tool with 5 optional params and no output schema, the description covers the return payload at a high level but omits pagination mechanics and how filters combine, leaving gaps an agent would need to close by trial. Adequate 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%, so the schema already documents all five optional filters including defaults and bounds. The description adds no syntax or filter-interaction detail beyond that, which is the expected baseline when the schema does the work.

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 OTC marketplace offers) plus domain (Cardano) and scope (peer-to-peer trading offers). An agent can distinguish it from create_otc_offer or fill_otc_offer, but it never explicitly contrasts with get_my_otc_offers or get_otc_offer_by_id, so the differentiation stays inferential.

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, no exclusions, and no alternatives named. With five closely related OTC siblings (get_my_otc_offers, get_otc_offer_by_id, create/fill/cancel), the routing burden is left entirely to the agent's inference 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully defines 'pending' as 'open' and notes orders are across various DEXes, but says nothing about authentication needs, read-only nature, pagination, or what an empty result means for a read tool operating on wallet data.

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

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

Two short sentences, zero filler, with the core action front-loaded in the first clause. The parenthetical gloss on 'pending' is a compact clarification rather than redundancy.

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

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

For a single-parameter read tool with no output schema, the description covers the basics but leaves the key ambiguity unresolved: how it differs from get_wallet_orders. An agent has enough to call it, but not clearly enough to choose 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%, with the single address parameter fully documented (bech32, addr1 prefix). The description only restates 'Cardano wallet address', adding 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?

States a specific verb (Get) and resource (pending swap orders) with scope (for a Cardano wallet address), and clarifies that 'pending' means 'open'. However, it does not differentiate itself from the sibling get_wallet_orders, which an agent could easily confuse it with.

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 the retrieval context but gives no explicit when-to-use guidance, no conditions that select it over get_wallet_orders or get_all_dca_orders, and no exclusions. The agent must infer the distinction purely from naming.

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

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

With no annotations, the description carries the full behavior burden. It usefully discloses that the return is a probability score where lower means safer, but says nothing about whether the read is cached/live, latency, rate limits, or behavior on an unknown or invalid assetId.

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 core action, then the return semantics. No filler — every sentence conveys new 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?

There is no output schema, and the description does partially compensate by explaining that the result is a probability score where lower is safer. It stops short of stating the scale/range or what a null/failure result looks like, but for a simple one-parameter read tool it is nearly sufficient.

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

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

Schema description coverage is 100% and the single assetId parameter is fully documented in 'policyId.assetNameHex' format. The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource (risk score for a Cardano native token) and clarifies the semantic meaning of the returned value. No sibling tool overlaps this function (all others are token search, pool, order, or swap operations), so disambiguation is inherent.

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 purpose — an agent can infer you call this when assessing scam risk for a specific token. However, there is no explicit when-to-use guidance, no mention of prerequisites (e.g., needing a valid on-chain assetId), and no statement of when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses what the call returns (liquidity, DEX names, pricing) which is real behavioral value, but it omits safety/permission requirements, rate limits, and whether results are exhaustive or paginated.

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, no filler. The purpose is front-loaded and the return-value context follows immediately; every clause earns its place.

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

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

For a four-parameter read tool with no output schema, the description covers purpose and gives partial return-shape context. It is nearly complete, missing only auth/pagination details that a fuller definition would provide.

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 all four parameters including the blacklisted_dexes example. The description adds no parameter-level syntax or format detail 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 ('Get available liquidity pools for a token pair across all Cardano DEXes') with clear scope. It doesn't explicitly name sibling alternatives like swap_aggregate or swap_build_cbor, but the discovery-vs-execution distinction is 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?

The phrase 'for finding the best swap routes' implies the usage context, but there is no explicit when-to-use versus sibling tools, nor any exclusions or prerequisites. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation and briefly notes the returned data can be limited and sorted, but says nothing about pagination, rate limits, auth requirements, or what fields 'trade data' actually contains, and there is no output schema to fill the 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?

Two tight sentences with the purpose front-loaded and no filler; the return-value note is brief. It is appropriately sized, though the second sentence adds little that the schema does not already convey.

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 three-parameter, zero-required read tool with full schema coverage and no output schema, the description is minimally adequate. Its key shortfall is failing to distinguish this tool from similarly named trade-fetching siblings, which an agent needs in order to select 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%, so all three parameters (limit, order, timeframe) are already fully documented in the schema with defaults and enum values. The description only restates 'configurable limit and sort order', adding no meaning beyond the schema, which matches the baseline 3 for high coverage.

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

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

The description states a specific verb ('Get') and resource ('token trades') with a scope qualifier ('across Cardano DEXes') and a timeframe, so the core purpose is clear. However, it does not differentiate itself from obvious siblings like get_global_trades or get_historical_trades, leaving an agent to guess which trade-fetching 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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives. Given the presence of get_global_trades and get_historical_trades, the absence of any routing guidance is a real gap, though the timeframe mention offers weak implied context.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the ranking basis (trading activity) and the dimensional scope (Cardano DEXes), but says nothing about auth requirements, rate limits, response shape, or empty-result behavior for a tool whose output schema is absent.

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 that names the resource, ranking, and scope with no wasted words. Structure is clean, though it is minimal to the point of omitting useful context rather than being wasteful.

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

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

For a two-parameter listing tool with no output schema and no annotations, the description covers the core intent but omits any indication of what a returned token record contains or how results behave at boundaries. Adequate but with clear gaps given the missing structured context.

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

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

Schema description coverage is 100%, so both parameters (count, timeframe) are fully documented in the schema. The description only echoes the timeframe dimension and adds no syntax, format, or default details beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb (get) and resource (trending tokens) with scope qualifiers (Cardano DEXes, ranked by trading activity, for a timeframe). An agent can identify the tool's function clearly. It does not explicitly differentiate from close siblings like search_tokens or get_rug_score, which would be needed for a 5.

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

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

The description implies a use case (viewing trending tokens) but gives no explicit when-to-use guidance, no prerequisites, and never names alternatives such as search_tokens. The agent must infer when this is preferable to browsing tokens another way.

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

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

No annotations are provided, so the description carries the full burden. It clarifies this returns both open and completed orders (a read-only lookup by nature) and enumerates the returned fields, but says nothing about auth requirements, pagination, or any limits on result size.

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, zero filler, with the operation and scope front-loaded and the return contents summarized second.

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

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

With no output schema, the description usefully summarizes the return payload (action type, tokens, amounts, DEX, status). For a simple single-parameter read tool this is nearly complete, though it omits ordering/pagination behavior.

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

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

Schema coverage is 100% and the single 'address' parameter is already documented as a bech32 Cardano address in the schema, so the description's mention of 'a Cardano wallet address' adds no new detail. 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 (swap orders) with scope narrowed to open and completed orders for a Cardano wallet address. It is largely distinguishable from get_pending_orders and get_dca_orders by scope, though it never names a 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 the scope claim ('all swap orders... for a Cardano wallet address'), but there is no explicit when-to-use guidance and the closely related sibling get_pending_orders is not mentioned as an alternative.

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

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

No annotations are provided, so the description carries the burden. It discloses what is returned (price, decimals, verification status), which is genuinely useful given there is no output schema, but it says nothing about auth requirements, rate limits, error behavior for unknown policy IDs, or read-only status.

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, front-loaded sentences with the core action first and the return fields immediately after. Efficient overall, though the closing valuation note is soft rather than actionable.

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

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

For a two-parameter read tool with no output schema and no annotations, the description adequately signals the return payload (metadata, price, decimals, verification status). It stops short of covering how the two parameters interact or any operational constraints an agent might need.

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 parameters are already documented by the schema. The description only restates the 'list of policy IDs' mapping to policyIdList and never mentions the optional hexList parameter or how it pairs with the IDs, so it adds little beyond the schema baseline.

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

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

The description states a specific verb and resource ('Get token details for a list of policy IDs') and enumerates the returned fields. It clearly identifies the resource as tokens keyed by policy IDs, though it does not explicitly contrast itself with sibling lookups like search_tokens or get_token_pools.

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 hint is 'Useful for portfolio valuation,' which implies a scenario but gives no when-to-use guidance, no prerequisites, and no routing away from the many sibling token tools (search_tokens, get_trending_tokens, get_token_pools).

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the return fields (policyId, asset name, decimals, price, verification status), which is useful, but says nothing about pagination, result limits, ordering, or that this is a non-mutating read. For a simple lookup tool this is adequate but shallow.

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

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

Two sentences, front-loaded with purpose followed by return values, with no filler. Every clause earns its place, particularly the field list given the absence of an output schema.

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

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

With no output schema, the description usefully enumerates the return fields, which is the key missing context an agent would need. It remains incomplete only in that it gives no usage guidance relative to sibling discovery tools, but for a one-parameter search it is largely sufficient.

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

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

Schema coverage is 100% and there is only one parameter, so the schema already documents the query fully (including examples and the empty-string default). The description restates the search-by-ticker-or-name intent but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('Search') and resource ('Cardano native tokens') plus the search criteria (ticker symbol or name). It also lists the returned fields. However, it does not differentiate itself from nearby siblings like get_trending_tokens or get_token_pools, so an agent still has to infer which search variant 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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The only hint about listing all tokens ('Leave empty to list all tokens') lives in the schema, not the description, so the description itself provides no 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?

With no annotations, the description carries the full burden. It usefully discloses that the call merely reports/logs the submission for analytics and tracking rather than executing a swap, which is meaningful behavioral context. However, it omits auth requirements, idempotency/duplicate-handling, and failure behavior.

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

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

A single front-loaded sentence with no filler; every word earns its place and the purpose leads 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 low-complexity reporting tool with a fully-covered schema, the description covers what it does, but with no annotations and no output schema it should say more about when to invoke it and what the backend does with the data (e.g., auth, failure handling).

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 five parameters (txHash, status, maker, staker, error) are already documented in the schema. The description adds no additional meaning about parameter formats or usage, 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 ('Log a swap transaction submission') and resource, and clarifies the destination ('the Cardexscan backend') and intent ('for analytics and tracking'). It is clear what the tool does, though it doesn't explicitly differentiate itself from sibling swap tools like swap_aggregate or swap_build_cbor.

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

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

There is no guidance on when to call this tool versus alternatives (e.g., after a swap has been submitted on-chain), nor any stated prerequisites or conditions. The 'log ... for analytics' phrasing implies a post-submission reporting step but leaves the trigger 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?

With no annotations, the description carries the full burden. It discloses return behavior (split routes, estimated output), and the verb 'Get' implies a read-only quote, but it never explicitly confirms execution does not occur, nor mentions permissions, rate limits, or freshness of the quote.

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 waste. The purpose is front-loaded and the return behavior follows immediately, fitting the description to the tool's scope.

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 5-parameter quote tool with a nested output-token object and no output schema, the description names the key return concepts (split routes, estimated amount) and the DEX-spanning scope. The main remaining gap is usage/sequencing guidance, which is captured under a separate dimension.

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

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

Schema coverage is 100%, so the schema already documents all five parameters including the native token format, slippage bounds, and blacklisted_dexes examples. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('Get') and resource ('aggregated swap data for a token pair across Cardano DEXes') and clarifies the output as optimal split routes plus estimated amount. This distinguishes it functionally from execution siblings like submit_swap and swap_build_cbor, though it never explicitly names 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 when-to-use, when-not-to-use, or alternative routing. Given siblings submit_swap and swap_build_cbor exist, the description should clarify this is a quote/aggregation step rather than an execution, but leaves the agent to infer that from 'Get' 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?

With no annotations, the description carries the full burden. It usefully discloses the key non-obvious trait that the returned CBOR is unsigned and must be signed externally, meaning the tool does not itself execute the swap. It omits auth/permission requirements, whether the build has side effects (e.g. order reservation), and any rate limits.

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

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

Two short sentences, front-loading the action and then the return value; every clause carries information. Nothing is padded or redundant.

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

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

There is no output schema, and the description does cover the return value (the CBOR to sign), which is the most important missing piece. However, for a mutation-adjacent tool with no annotations it should also state auth prerequisites, error conditions, and where this fits in the swap flow; those gaps keep it at adequate rather than 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 all six parameters including the nested tokenOut object are already fully documented in the schema. The description adds no parameter-level meaning, which is acceptable at this coverage level but is the baseline rather than a value-add.

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 ('Build an unsigned transaction CBOR for an aggregated swap') and the 'unsigned' qualifier distinguishes it from a submit/sign tool. It does not, however, name the sibling tools (e.g. swap_aggregate, submit_swap) that an agent must choose between.

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 'needs to be signed by the user's wallet' implies this is a build step preceding signing/submission, so usage is inferable. But there is no explicit when-to-use, no stated prerequisites (e.g. wallet connection), and no named alternatives.

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