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

Annotations cover the safety profile (readOnly, non-destructive, open-world, non-idempotent), and the description goes well beyond them: exact cost and currency, network (Base Sepolia / Circle testnet USDC), the x402 payment path, which wallet key is debited, that no key means no call, and that 400/404 responses are free. These are the operational facts an agent needs before invoking a paid 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?

Front-loaded with the identity of the index and its scope, then the negative (no market prices), then payment mechanics. Sentences are dense but each carries distinct information. The payment clause is long but earns its place given the paid nature of the tool.

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

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

With no output schema, the description carries the burden of describing returns, and it does name the content (weekly counts, totals, GCAT attribution). Payment, auth, and error-cost behavior are all covered. The only gap is the absence of an explicit boundary against smi_get_latest, which is minor relative to what is provided.

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

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

There are zero parameters, so the baseline is 4. The description compensates by explaining the return content (weekly counts, totals, GCAT attribution) even though it has no inputs to document.

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

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

The description states a specific resource and scope: weekly orbital launch counts for the year so far, with totals and GCAT attribution, plus an explicit negative (contains no market prices). That cleanly separates it from smx_* market tools. It never names smi_get_latest, the obvious sibling for the current week, so the differentiation from that tool is left to inference.

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

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

It gives a hard prerequisite (X402_PRIVATE_KEY must be set or the tool makes no call) and states that 400/404 errors are not charged, which is genuinely useful invocation guidance. However, there is no explicit when-to-use-this-vs-smi_get_latest routing, which is the most likely agent confusion given the sibling names.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real context beyond that: 'Information only; contains no market prices' and 'Free, no key' disclose content scope and auth requirements, which the annotations do not.

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

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

Dense but purposeful: the core action comes first, return contents follow, and the operative constraints ('no market prices', 'Free, no key') land early enough. The sub-index list is long but serves a real disambiguation purpose.

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

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

With no output schema, the description compensates by describing the returned shape and its scoping/legal caveats. It is complete enough to call correctly for a single-optional-parameter read tool, though it omits pagination/size expectations.

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 enum values are fully enumerated, so the baseline is 3. The description's note about passing sub_index to get one sub-index in full essentially restates the schema's own description rather than adding format or default-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?

States a specific verb and resource ('the latest weekly print' of the SMI) and enumerates exactly what it returns (headline figure, one-line summary per sub-index, print id, data dates, rules links, GCAT attribution). The word 'latest' implicitly separates it from smi_get_history/smi_get_print without ambiguity.

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

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

The usage context is implied by 'latest weekly print' and the pointer to 'Pass sub_index to get one sub-index in full', but no sibling (e.g. smi_get_history for past prints, smi_get_print) is named and no when-not condition is given. Adequate but leaves the alternative-selection to inference.

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

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

Goes well beyond the annotations: it discloses the paid nature ($0.01 in testnet USDC on Base Sepolia via x402), that the charge hits the caller's own wallet via X402_PRIVATE_KEY and that the tool makes no call without it, and that 400/404 errors are not charged. This is exactly the auth/cost context annotations cannot express, and it is consistent with readOnlyHint=true and idempotentHint=false.

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 identity and payload fields before the payment caveats, so the critical information comes first. Minor redundancy ('Circle testnet USDC on Base Sepolia via x402, testnet USDC, no real value') costs a point but does not obscure 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 tool with no output schema, the description covers the resource, the identifier format, the returned fields, and the full payment/auth/error-charging model. An agent has everything needed to decide and invoke 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% and the single launch_id parameter is fully documented with pattern and example in the schema; the description only repeats the id concept and the same example. Baseline 3 applies since the schema carries the semantics.

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

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

States a specific verb+resource+scope: 'one orbital launch by GCAT launch id', and enumerates the returned fields (date, rocket, mission, agency, payloads, mass status). The 'by id / one record' framing distinguishes it from the sibling smi_get_latest and smi_get_history without needing their 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?

The description implies usage through the id-based lookup and gives a concrete example id, but never states when to prefer this over smi_get_latest or smi_get_history, nor any prerequisites beyond the payment note. Usage is inferable but not spelled out.

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

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

Annotations already cover readOnly, idempotent, non-destructive and openWorld, so the safety profile is carried by structured data. The description adds credit-worthy behavioral context beyond that: the resource is free and requires no API key, which affects how an agent authenticates and budgets. It does not contradict annotations; it only omits output shape and any rate-limit notes.

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, front-loaded with the tool's identity and contents before the call hint. Every clause earns its place; only the parenthetical list of contents makes it slightly dense.

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, no-required-param tool with a fully documented enum and no output schema, the description is sufficient: it names the sections and the calling pattern, so an agent can invoke it correctly 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?

With one optional parameter and 100% schema description coverage plus an enum of all nine section values, the schema does the heavy lifting. "Pass section to get one part" reinforces the semantics without adding format or default details, which is the expected baseline at 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?

States a specific verb+resource (get methodology) and enumerates the content actually returned: version, change log, conflicts statement, headline formula, counting rules. It is unambiguous what the tool does, though it doesn't explicitly contrast itself with index-value siblings like smi_get_latest or smi_get_print.

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?

"Free, no key. Pass section to get one part." gives a practical calling hint and cost note, but there is no explicit when-to-use/when-not-to-use guidance relative to the many smi_/smx_ siblings. Usage is implied rather than stated.

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

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

Annotations cover safety (readOnly, non-destructive, openWorld), but the description adds behavior they cannot convey: per-call cost, payment rail (x402, Circle testnet USDC on Base Sepolia), that value is testnet-only, which credential is debited, that no network call occurs without the key, and that failed requests are not billed.

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 identity and scope, then payment mechanics, then error billing. Dense but every clause is load-bearing (cost, credential, no-call condition, non-billing errors). Slightly packed into one paragraph rather than split, but no filler.

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

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

For a paid, single-param lookup with no output schema, it covers cost, prerequisites, failure billing, and content scope ('information only; contains no market prices'). It stops short of describing the shape of the returned print, which is the only meaningful gap.

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

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

Schema description coverage is 100% and the single parameter already carries both the pattern and the '2026-W39.r7' example, so the description's example repeats rather than extends the schema. Baseline 3 for a fully documented single-parameter 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: fetch one archived weekly SMI print by print id, with a concrete id format example (2026-W39.r7). This distinguishes it from siblings smi_get_latest (latest) and smi_get_history (range), and the publisher is named.

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

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

Gives clear invocation context: it is a paid call ($0.01 USDC), requires X402_PRIVATE_KEY in the caller's environment, and 'without it the tool makes no call.' It also notes errors 400/404 are not charged. It does not explicitly route the agent between this and smi_get_latest/smi_get_history, so it stops short of full alternative guidance.

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

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

Annotations already mark it read-only and non-destructive, and the description adds material context beyond them: cancelling an unclaimed fill would forfeit it on the current contracts, the call returns claim calls to make, state is read at call time and provided as-is, and it is free with no key. This is exactly the operational safety detail an agent needs.

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 trigger and the key outcome, and every sentence carries substance. It is slightly repetitive — 'Read-only; never cancels or claims' is restated by 'Read-only check of on-chain state at the time of the call' — which keeps it from a top score.

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

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

No output schema exists, yet the description explains what comes back (safeToCancel=false plus claim calls), why it matters, the cost model, and the freshness caveat. Nothing an agent needs to call and interpret this correctly is missing.

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

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

Schema description coverage is 100% and both parameters are documented there ('Market id from smx_list_markets', 'Your order ids on that market's order book'). The description adds no syntax, format, or batching 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: 'check each order for unclaimed fills' before cancelling. The scope (SMX testnet orders in your own wallet) and the exact output condition (safeToCancel=false) make it unambiguous and clearly distinct from the market/methodology 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?

Gives a clear trigger — do this before cancelling orders from your own wallet — and reinforces it with 'Verify before acting.' It doesn't name any alternative tool or an explicit when-not case, but no sibling in the list plausibly competes for this job.

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 openWorld. The description adds genuinely new operational context beyond that: the data is read from chain, no API key or payment is required, and the market is testnet-only with 'Test USDC, no monetary value' — a meaningful safety disclosure for a trading-adjacent 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?

Front-loaded with the resource and then the return fields in one dense but information-bearing sentence, followed by two short constraint fragments. Every clause carries payload or constraint information; the enumeration is long but not padding.

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

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

With no output schema, the description carries the return-value burden and does so by listing the returned fields, including the aggregated order book. Combined with the testnet/no-key/no-value caveats, an agent has enough to call this correctly; only the paid-vs-free routing is left unstated.

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

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

Schema coverage is 100% and the single id parameter is fully documented in the schema, including an example format and its source (smx_list_markets). The description adds nothing about the id beyond what the schema already provides, 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?

Names a specific resource and scope: 'One SMX testnet market', and enumerates the payload (question, state, outcome, best bid/ask, YES midpoint, order book). The singular scope implicitly separates it from smx_list_markets, and 'Free, no key' implicitly separates it from the smx_paid_* siblings, though neither alternative is named outright.

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

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

Usage is only implied: the agent infers this is the single-market lookup used after smx_list_markets returns an id. There is no explicit statement of when to prefer this over smx_paid_get_market or smx_paid_get_mid, which is a real ambiguity given both exist in the sibling set.

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, openWorld, non-destructive), so the bar is lower. The description still adds real value beyond them: the on-chain source, consistency with the agent API listing rules, that it is free/no-key, and that the USDC is testnet with no monetary value. It does not disclose pagination or result limits, keeping it short of a 5.

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

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

Front-loads the core action and scope, then enumerates returned fields — each sentence carries information, especially the field list, which is needed since there is no output schema. Slightly dense, 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?

With no output schema, the description carries the return-value burden and does so by enumerating the per-market fields (id, title, state, status, outcome, bid/ask, YES midpoint in bps, minimum order) plus the bps unit convention. Combined with annotations covering safety, an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100% and the single parameter include_unlisted is fully documented there. The description adds no syntax or default information for it, so the schema does the heavy lifting and 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 ('List SMX event markets') and pins the exact data source (on-chain MarketRegistry on Base Sepolia). The 'Free, no key' clause implicitly distinguishes it from the sibling smx_paid_list_markets, so an agent can route without opening a schema.

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

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

Gives clear usage context: free, no key required, testnet, no monetary value, and listing rules matching the SMX agent API. It does not explicitly name alternatives (e.g., smx_get_market for a single market, or the paid variants), so no exclusions are stated, but the practical context is unambiguous.

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

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

Annotations already declare readOnly/openWorld/non-idempotent, but the description adds substantial context they don't carry: the $0.01 charge in testnet USDC on Base Sepolia via x402, the X402_PRIVATE_KEY requirement (no key = no call), and that 400/404 responses are not billed. This is exactly the extra behavioral detail an agent needs before invoking a paid 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?

A single dense paragraph that is front-loaded with the endpoint and resource, then payment mechanics. Every clause earns its place, though the payment sentence is somewhat packed.

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

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

With no output schema, the description compensates by listing the returned fields, and it fully covers payment, auth, and error-charging behavior. An agent has everything needed 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 description coverage is 100% and the single parameter is fully documented in the schema (pattern plus 'Market id from smx_list_markets'). The description adds no further parameter 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?

Names a specific verb+resource ('market detail'), the exact endpoint (GET /agent/markets/{id}), and enumerates the returned fields (status, outcome, midpoint, minimum order, book summary). It clearly distinguishes itself from the sibling smx_get_market by being the paid 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?

Gives clear conditions around cost and the wallet-key prerequisite, and states that errors are not charged. However, it never explicitly tells the agent to prefer smx_get_market when payment is unnecessary, leaving the paid-vs-free choice to 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?

Annotations only cover read-only/open-world/idempotency hints; the description adds substantial behavioral context: exact payment amount and chain/asset, the env var that funds the charge, the consequence of missing it (no call), and the billing exception for 400/404. It also flags a field-format gotcha (legacy midCents is in basis points), which explains why the call is non-idempotent from a cost perspective.

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

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

One dense, front-loaded paragraph: what it returns first, then the midCents unit warning, then payment/auth mechanics, then error billing. Every sentence carries information an agent needs and none 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, the description enumerates the returned fields and their semantics (5000 = 50 cents) plus the payment prerequisite, so an agent can call and interpret results correctly. Nothing material is missing for a single-parameter read tool.

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

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

Schema description coverage is 100% and the single 'id' parameter is already documented with its source (smx_list_markets) and pattern. The description restates that it targets one market but 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?

States a specific verb/resource (midpoint), names the exact endpoint (GET /v1/markets/{id}/mid), and scopes it to one SMX testnet market. The returned fields (midBps, midPriceCents, source, status) make the resource unambiguous, and the 'paid' framing separates it from the free sibling smx_get_market.

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?

Clear context: paid $0.01 call requiring X402_PRIVATE_KEY, and explicitly states no call is made without that key, plus errors 400/404 are not charged. It does not explicitly contrast itself with the free smx_get_market sibling, so the agent must infer when the paid path is warranted.

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 by disclosing the exact price ($0.01 in Circle testnet USDC on Base Sepolia via x402), which wallet key is charged, that the tool makes no call without X402_PRIVATE_KEY, and that 400/404 errors are not billed. This is precisely the operational context an agent needs before invoking a paid 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?

Information is front-loaded (what it returns, then cost/mechanics) and every clause carries signal. Minor redundancy in restating 'SMX agent API market list' alongside the endpoint path and 'as served by the SMX agent API' costs it the top score.

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

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

No output schema exists, so the description compensates by naming the returned fields, and it covers payment mechanics, credential requirements, and error-billing behavior. Nothing an agent needs to call this paid endpoint correctly is missing.

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

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

With a single optional parameter at 100% schema description coverage, the schema already fully documents the `all` flag. The description's phrase 'the listed SMX testnet markets' loosely implies the default listed-only behavior, but adds no syntax or semantics beyond what the schema provides — 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/resource combination ('market list' via GET /agent/markets) and enumerates the returned fields (status, outcome, midpoint with midBps/midPriceCents, minimum order). It explicitly distinguishes itself from the sibling smx_list_markets by naming it and noting it serves identical data.

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

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

Names the free alternative (smx_list_markets) directly, which is the key routing decision for the agent. However it never states positively when the paid variant should be preferred over the free one, leaving the choice implicit rather than giving an explicit condition or exclusion.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond annotations: it is free, requires no key, and returns specific procedural information including a 'claim-before-cancel safety rule,' which is crucial operational knowledge for the agent.

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

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

Two well-structured sentences front-load the purpose and key operational facts. Every sentence earns its place with no redundancy.

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

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

Given that this is a read-only informational tool with no output schema, the description provides sufficient context: it explains what the tool returns (steps, addresses, rules) and its limitations (cannot trade). Minor gap: it does not explicitly state the return format or whether the response is structured, but the overall description is complete for an agent to decide when to call it.

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

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

Schema description coverage is 100%, and the single optional parameter 'id' is fully documented in the schema as an optional market id that fills in that market's order book address. The description does not mention the parameter, but with full schema coverage, the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: it returns steps, contract addresses, and order rules for placing, cancelling and claiming SMX testnet orders. It clarifies a key distinction from siblings by noting 'This server cannot trade; it returns the exact steps,' which tells an agent this is a guide, not an execution tool.

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

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

The description provides clear context: use this when you need to know how to trade from your own wallet on Base Sepolia. It does not explicitly list when to use other siblings, but the framing ('from your own wallet', 'server cannot trade') implies it is for guidance rather than market lookup or status checks.

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