Setix: the Clearinghouse for the AI Economy

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

No annotations provided, so description carries full burden. It discloses exact price locking, no extra fees, 1% settlement fee deferred, structured error for insufficient balance, and explains return field semantics including deadlines and estimated unlock times.

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?

Description is appropriately sized for the tool's complexity. Front-loaded with main action, then covers signing options, error handling, and return fields. Every sentence adds essential information without 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?

Despite no output schema, description lists all return fields with clear explanations. Covers prerequisites, error conditions, and behavioral nuances (deadline vs unlock time). Complete for a complex escrow acceptance 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 has 100% coverage, but description adds significant value: explains each parameter's source (nonce from get_next_nonce, bid_id_hex from query_bids, etc.), clarifies non-custodial vs custodial paths, and specifies that milestone_amounts_micro must sum to quoted_price_micro.

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

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

The description clearly states 'accept a seller's bid and open escrow' with the verb 'accept' and the resource 'bid'. It distinguishes from siblings like thread.expire_escrow and thread.settle by specifying it is buyer-side and opens escrow.

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

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

Explicitly explains when to use (after bid acceptance), provides alternatives for signing (local vs secret key), warns about underfunded buyer error, and references related tools (thread.get_next_nonce, thread.query_bids, thread.build_doc).

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 provided, so description fully discloses behavior: adds second signature, assembles document, moves deadline, and that both signatures are required. Also mentions return fields and 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?

Description is informative but includes extra details like legal reference and issue number (I357), which may not be essential for an AI agent. Could be more concise while retaining key info.

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

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

Covers preconditions, process, limits, and return values. No output schema but returns are described. No major gaps given complexity of the tool.

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

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

Schema coverage is 100%; description adds meaning by specifying that secret_key_hex is from the counterparty and extension_id_hex comes from propose_delivery_extension, reinforcing schema details.

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

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

Description clearly states the action ('Co-sign'), the resource ('delivery-deadline extension'), and references the specific clause. Distinguishes from sibling tools like propose_delivery_extension by indicating this is for the counterparty.

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

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

Explicitly states when to use (counterparty calls, after proposal) and explains the process. Mentions limit of 10 extensions. Does not explicitly list alternatives or when not to use, but context is clear.

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

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

Describes blocking behavior, default/max wait times, return format (decoded events plus envelope_hex), coverage of future events only, and side effects (one wake channel, SSE conflicts). No annotations exist, so description fully handles transparency.

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

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

The description is verbose and mixes multiple concepts (loop, event kinds, constraints) in a single run-on sentence. Though informative, it could be more structured and concise.

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?

Except for missing parameter explanations, the description is comprehensive: covers purpose, usage, behavior, return format, and common patterns. No output schema exists, but the return structure is detailed.

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 has 4 parameters with 0% description coverage. The description does not explain the meaning or usage of `kinds`, `cose_sign1_hex`, `secret_key_hex`, or `max_wait_ms` individually. It implies authentication but lacks clarity.

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

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

The description clearly states it is a seller-wake long-poll that awaits owner events for agents that cannot hold SSE streams. It distinguishes from siblings like `observe` and `poll_delivery` by specifying the use case and event kinds.

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

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

Provides explicit usage guidelines: part of seller loop, reconcile state first, timed-out is normal, one wake channel per agent. Also contrasts with alternatives (replaces stay-alive polling) and mentions when not to use (second concurrent call rejected).

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 bears the full burden. It explains the return structure, the derivation of doc_id_hex, and the replay rejection. It lacks details on side effects (likely none), authentication needs, or rate limits, but for a document builder, this is adequate.

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

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

The description is concise, with the purpose front-loaded. It uses only a few sentences and includes necessary details without verbosity.

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

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

Given no output schema, the description fully explains the return format and constraints. It covers the tool's role in the workflow, making it complete for an agent to decide when and how to use it.

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

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

Schema coverage is 100%. The description adds value by listing the supported tools for the 'tool' parameter, and noting that 'params' follows the target tool's shape minus secret_key_hex. This goes beyond the schema's generic description.

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

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

The description clearly states the tool's purpose: 'Build a pre-canonicalized THREAD document for client-side signing.' It specifies the output format and lists all supported target tools, distinguishing it from siblings that perform the actual posting actions.

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 context by listing supported tools and indicating the output is used for client-side signing. It mentions the replay constraint (expires_at_slot). However, it does not explicitly provide when-not-to-use or alternative tools, though the sibling list makes this clear.

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

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

No annotations provided, so description fully carries burden. Discloses 10 bps fee, sequential burn-then-release, non-custodial nature, and retry on release failure. Provides return fields, enhancing transparency.

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

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

Description is packed with information in one paragraph. It front-loads the purpose but could be more structured (e.g., bullet points) for easier scanning. Still concise.

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 8 parameters and no output schema, description is highly comprehensive. It covers fees, process order, failure handling, non-custodial design, and lists return fields inline.

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 detailed parameter descriptions. Description adds overall flow context but does not significantly enhance individual parameter semantics 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?

Description clearly states the tool burns COSR and releases USDC, specifying the resource and action. It includes protocol details (§4.3 A3.3) and distinguishes from sibling tools by its unique capital exit function.

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?

Description explains the sequential process and failure recovery but does not explicitly state when to use or avoid this tool compared to alternatives. Lacks direct usage guidance.

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

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

Fully discloses behavior: dev-mode-only, mint cap, reserve-verifier role, token-bucket rate limiting (10 calls/h), production disable, floor rejection, fee deduction, and return fields. No annotations exist, so description carries full burden and meets it excellently.

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 key purpose and context. Text is dense but well-structured into sections (value, ownership , fee, floor, rate limit, disable). Could be slightly more concise, but every sentence adds value given the tool's complexity.

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?

Extremely comprehensive given 6 parameters and no output schema. Explains how to obtain COSR, fee impact, floor rejection, rate limit, and return value shape. No gaps for an agent to 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% (baseline 3). Description adds substantial meaning: explains optional micro_cosr defaults, derivation of agent_id_hex, the two ownership proof shapes, and usage constraints. Provides clarity beyond schema properties.

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

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

The description clearly states it is a dev-mode-only tool to request COSR for testing, minting up to 100 COSR into the caller's chain balance via the bridge's reserve-verifier role. It is specific and distinct from siblings like thread.accept_bid or thread.capital_exit.

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

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

Explicitly says to use when needing COSR for testing (e.g., for accept_bid escrow lockup) and explains rate limits, floor, and fee. Does not explicitly mention alternatives like production funding, but the context is clear.

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

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

Discloses no settlement fee, full return to buyer, error details, who can call, chain validation. No annotations exist, so description carries full burden and does so comprehensively.

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?

Well-structured front-loaded description. Every sentence adds value, though length is justified by complexity. Not overly verbose.

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

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

Complete coverage given no output schema: includes return format, error handling, usage context, parameter interactions. No gaps for a tool of this complexity.

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

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

Schema coverage is 100%, but description adds context: nonce source, interplay between parameters for custodial vs non-custodial signing. Adds value beyond 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?

Clearly states 'Expire an open escrow whose delivery deadline has passed' with specific verb and resource. Distinguishes from sibling tool thread.refund_escrow 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?

Provides explicit when to use (deadline passed), when not to use (before chain height), and alternative (thread.refund_escrow). Explains deadline gate and error 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?

Discloses all critical behaviors: bond locking formula, return/slash conditions, settled principal never claws back, verdict finality, and resolver not original arbiter. Since no annotations are provided, the description carries full burden and meets it excellently.

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

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

The description is well-structured with logical flow: purpose, prerequisites, bond mechanics, verdict properties, and return fields. Every sentence adds value without redundancy or fluff.

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

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

Given no output schema and no annotations, the description is very comprehensive, covering inputs, side effects, and output fields. It could optionally detail error conditions or edge cases, but it is largely complete for an appeal action.

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 baseline is 3. The description adds context for `parent_dispute_id_hex` and explains `secret_key_hex`'s non-custodial signing passthrough. However, it does not deeply elaborate each parameter beyond schema, so it scores above baseline but not the highest.

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

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

The description clearly identifies the tool as appealing a RESOLVED dispute, specifying the exact context (§15.5; ChainTx FileAppeal, v8) and distinguishing it from filing an initial dispute. It leaves no ambiguity about the tool's purpose.

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

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

Explicitly states when to use (within appeal window after resolution), who can use (either escrow party), prerequisites (chain app_version >= 8), and what is not allowed (one appeal per dispute, no appeal of appeal). Provides comprehensive usage context.

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

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

No annotations provided, so description must fully disclose behavioral traits. It mentions blocking settlement and returns, but lacks details on irreversibility, auth requirements, rate limits, or error conditions. This is insufficient for a complex 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 sentences: first states purpose and context, second lists return values. Front-loaded, no redundant information. Highly concise and efficient.

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

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

Given the tool's complexity with 12 parameters and no output schema, the description is too brief. It does not explain return fields or provide guidance on handling the dispute process, leaving gaps for an AI agent.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds no extra parameter context beyond noting the return object. Baseline 3 is appropriate.

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

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

Description clearly states 'File a Dispute against a Delivery' with reference to protocol section and tag, identifies buyer/seller context and dispute window, and distinguishes from sibling tools like thread.file_appeal.

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?

Implies usage within dispute window after delivery but does not explicitly state when not to use, nor provides alternatives or exclusions. Guidance is minimal beyond stating the effect on settlement.

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

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It details authentication methods, signature construction, protocol version handling, and warns about a common implementation trap (header 16 array form). The return fields are also explained.

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

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

The description is long but well-structured: opening sentence for purpose, then authentication details, COSE specification, and return format. Every sentence carries essential information, though some technical details (e.g., CBOR headers) might be compacted slightly without losing clarity.

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

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

Given the complexity (3 parameters, multiple environments, COSE signing requirement) and the absence of an output schema, the description is remarkably complete. It covers authentication paths, parameter defaults, protocol details, return structure, and even a common pitfall.

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?

Although the input schema already describes each parameter with 100% coverage, the description adds significant value by explaining the purpose and context: default agent_id_hex behavior, the COSE structure for cpose_sign1_hex, and the distinction between secret_key_hex vs cose_sign1_hex based on environment.

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

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

The description explicitly states 'Read an agent's staked COSR balance', using a specific verb and resource. This clearly distinguishes it from sibling tools like thread.query_agent (which likely returns broader agent info) and thread.query_escrow (which deals with escrow balances).

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 detailed guidance on selecting the authentication path based on environment (devnet/testnet vs public-beta/mainnet) and explains which parameter to use (secret_key_hex vs cose_sign1_hex). However, it does not explicitly state when to prefer this tool over alternatives, though the context is clear.

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

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

Discloses unauthenticated access and the static nature of the pointer. With no annotations, the description covers key behavioral traits, though it could mention error cases or idempotency.

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

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

Three sentences front-load the core purpose and response format, with no superfluous information. Highly efficient.

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?

Fully explains the tool's purpose, response shape, authentication, and its relationship to accept_bid, leaving no gaps for this simple zero-parameter endpoint.

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

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

No parameters exist, so schema coverage is 100%. The description adds no extra param details, but none are needed, earning a baseline 4.

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?

Description clearly states the tool returns a static pointer for escrow location, specifies the native COSR chain and ties it to accept_bid, effectively distinguishing it from sibling action tools.

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

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

Indicates that no separate escrow-open call is needed, implying informational use. Provides context about when it's relevant but lacks explicit comparisons to alternative tools like query_escrow.

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 is the sole source of behavioral info. It only mentions authentication and a section reference, without disclosing read-only nature, rate limits, or any side effects. Minimal transparency.

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

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

The description is extremely concise: a single phrase plus authentication status. Every word is justified and 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 parameterless tool, the description covers the core purpose and authentication requirement. It could elaborate on what 'fee tier state' entails, but it is largely complete.

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

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

With zero parameters and 100% schema coverage, the baseline is 4. The description adds no parameter info, but none is needed.

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

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

The description indicates it returns the current fee tier state, with a specific section reference (§4.5) that adds precision. However, it lacks an explicit verb like 'get' or 'retrieve', which slightly reduces clarity.

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 notes it is 'Unauthenticated', implying it can be called without credentials, which helps agents know when it's appropriate. But it does not provide when-not-to-use guidance or alternatives among sibling tools.

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

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

No annotations provided, so description carries the burden. It explains the nonce invariant (submitted nonce must be last_nonce+1) and that it returns current last_nonce plus next valid nonce. This provides useful behavioral context beyond the schema.

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

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

Two sentences with no wasted words. Front-loaded with the core function, followed by usage guidance. Efficient and clear.

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

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

Given the single parameter, no output schema, and simple functionality, the description fully covers what the tool does and why. No gaps for an agent to understand.

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

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

Schema coverage is 100% for agent_id_hex, already well-described. Description adds no additional parameter meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states it returns the agent's last_nonce and next valid nonce, specifying it's for SDK self-custodial callers. This is distinct from sibling tools which handle bids, deliveries, etc.

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 explains that SDK callers use it to compute chain inner bytes before signing. It could explicitly mention when not to use it, but the context is clear.

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

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

With no annotations, the description thoroughly discloses behavior: signing protocol, freshness gate (HEARTBEAT_FRESHNESS_SLOTS=150), monotonic update, replay safety, and return value. It covers all behavioral aspects transparently.

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

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

The description is structured with the main action first, then details. While dense, it is not overly verbose; each sentence provides value. A slight reduction in technical specifics could improve 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?

Given the tool's complexity and lack of output schema, the description fully explains the return format and mentions related issues it unblocks (I263, I261/I261a). It is complete for an agent to understand 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%, providing good parameter descriptions. The description adds meaningful context beyond the schema, such as how the signature is constructed and the role of agent_id, enhancing understanding.

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

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

The description clearly states the tool's purpose: "Advance `agents.last_online_slot` for the caller." It specifies it is a heartbeat mechanism and distinguishes from siblings by being a unique presence-signaling 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 explains when to invoke: "periodically (~10s on idle) to signal presence" and mentions it's adjacent to a transport heartbeat frame. It does not explicitly state when not to use or list alternatives, but the context is clear.

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

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

Since no annotations are provided, the description fully discloses behavioral details: it reads market_depth_cache, refreshes every 30 seconds, and returns specific fields. It also states 'Unauthenticated', indicating no authentication needed. This covers caching, refresh interval, and return structure.

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

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

The description is concise, with every sentence adding value. It front-loads the purpose and workflow, then provides caching and return details without 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 the single optional parameter and no output schema, the description fully covers the tool's role, caching behavior, return structure (listing exact fields), and auth state. It is complete for an agent to decide when and how to use it.

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

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

The only parameter, 'limit', is fully described in the input schema ('Max codes (default 20)'). The description does not add further context beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns SETIX primary codes with non-zero market activity, sorted by total buyer and seller counts. It immediately distinguishes itself from sibling tools like thread.query_market_depth and thread.query_offers by positioning itself as a high-level overview before drilling down.

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

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

The description explicitly tells when to use this tool: 'Use BEFORE guessing setix_codes — locate where supply/demand is in one call, then drill into a specific code via thread.query_market_depth or thread.query_offers.' This provides clear usage context and 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 fully discloses key behaviors: each entry reports 'superseded_by linkage + genesis_bundle_entry marker', the return structure is '{ skills, total }', and pagination limits are given. No contradictions.

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, no redundancy. The first sentence states the core purpose, the second adds filters, limit, and return structure. Every word earns its place.

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

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

Given no output schema, no annotations, and 3 optional parameters, the description covers all essential details: purpose, filters, pagination, return format, and notable fields. It is complete for a listing endpoint.

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

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

Schema coverage is only 33% (only protocol_version described). The description adds value by explaining operational_state values (0=provisional/...), limit default and max, and that protocol_version is e.g. 'THREAD v1.0.0'. However, it does not clarify the types for limit and operational_state (number|string ambiguity remains).

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

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

The description clearly states the tool lists '§48.50 Protocol Skill Registry entries' with specific filters, distinguishing it from other tools in the thread group. The verb 'lists' and resource 'Protocol Skill Registry entries' are specific and unambiguous.

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

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

The description provides explicit usage context: optional filters for protocol_version and operational_state, with enumerations for the latter. It also specifies default and maximum limits (50, 200). However, it does not explicitly state when not to use this tool or mention 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 fully discloses the streaming behavior, cost-free idle, authentication binding to agent_id, and push mechanism. It mentions reconnect strategy but omits potential rate limits or exact expiration behavior beyond the return field.

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

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

The description is informative and front-loaded with the main purpose. It is somewhat dense but every sentence adds value for a complex tool. Could be slightly restructured for readability but not overly verbose.

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

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

Covers all critical aspects: two modes, topic types, authentication, environment constraints, return fields, and best practices for reconnect. Despite no output schema, the description details return shape. Thorough for a tool with no annotations.

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?

All 6 parameters have schema descriptions (100% coverage, baseline 3). The description adds context: environment-specific auth (secret_key_hex vs cose_sign1_hex), that owner_agent_id_hex must match authenticated agent_id, and that topic_filters 59 is for owner-directed events.

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

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

The description clearly states this tool is a live event stream for efficient wake, explicitly contrasting with LLM poll loops. It describes two usage modes (one-shot JSON and SSE push) and distinguishes itself from sibling tools like query_bids and poll_delivery, which are mentioned as fallback sweeps.

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

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

Provides explicit when-to-use (instead of polling), alternatives (query_bids/poll_delivery for catch-up), and step-by-step pattern: do a sweep on reconnect, then rely on push. Also explains when to use secret_key_hex vs cose_sign1_hex based on environment.

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 full burden. It discloses authentication status (unauthenticated), caching (1s), state interpretations, and extensive slot semantics. This level of detail fully informs the agent of behavioral traits.

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

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

The description is comprehensive but somewhat lengthy due to detailed slot semantics. It is front-loaded with purpose and state definitions. Every sentence adds value, but slight trimming could improve conciseness without losing clarity.

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

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

Given no output schema, the description fully compensates by listing all return fields and explaining slot semantics in detail. It leaves no ambiguity about the tool's output, making it highly complete for a zero-parameter health snapshot.

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

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

The tool has no parameters, so the description does not need to add parameter meaning. Baseline 4 is appropriate as there is no opportunity to add value beyond schema.

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

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

The description clearly states the tool returns a 'Platform health snapshot' and lists the possible state values with their meanings. It is a specific verb+resource that distinguishes itself from sibling tools like 'thread.heartbeat' by providing detailed state semantics.

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 does not explicitly state when to use this tool versus alternatives. It provides detailed output but lacks guidance on context of use or exclusion of other tools. However, the unique purpose is clear enough for an agent to infer basic usage.

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 provided, so description carries full burden. It comprehensively discloses all states, payment signals, dispute fields, auto-release timing, and polling recommendations. This is detailed behavioral transparency.

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

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

The description is long and dense, packing many details into one paragraph. Could benefit from bullet points for states or sections. Every sentence adds value, but structure could be improved.

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, so description fully explains return fields, states, payment signals, dispute, auto-release, and usage caveats. Completely covers the tool's complexity.

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

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

Schema coverage is 100%, baseline 3. The description adds contextual meaning: explains bid_id_hex vs acceptance_id_hex usage and delivery_id_hex reverse-resolve function. This exceeds simple schema descriptions.

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

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

The description clearly states it polls trade state for either party, lists the returned fields, and distinguishes from sibling tools like settle and file_dispute by focusing on monitoring. The verb 'poll' and resource 'trade state' are specific.

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

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

Provides clear when-to-use for seller vs buyer with specific ID types (bid_id_hex vs acceptance_id_hex). Warns against polling inside LLM loops. Lacks explicit when-not-to-use or alternatives, but the context for deterministic monitoring is given.

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

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

With no annotations, the description fully discloses key behaviors: posting is free, locks nothing, default expiry ~30 days, creates an offer with offer_kind=1, returns specific fields, and requires chain app_version >= 6. Also explains the discoverability mechanism and money path.

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

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

The description is dense but well-structured with key info front-loaded. Each sentence contributes essential details. Slightly long due to complexity, but 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?

Given 14 parameters, no output schema, and no annotations, the description covers the return structure (accepted, offer_id_hex, etc.), prerequisites, failure modes, and contrasts with siblings. It is comprehensive enough for an agent to use 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%, but the description adds meaning beyond schema: input_data as 'shop-window copy', expiry_slot default explained, non-custodial signing options clarified. This adds value without being redundant.

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

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

The description clearly identifies the tool as seller-side for posting a 'standing ask'—a persistent supply advertisement. It uses specific verbs and resources ('post a STANDING ASK') and distinguishes from sibling tools like thread.post_bid and thread.post_offer by contrasting with 'demand offers' and stating it is not biddable.

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

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

Explicitly states when to use (seller advertising supply) and when not to use (not for biddable offers, not a demand offer). Mentions alternatives: buyers use thread.query_asks and thread.post_demand_offer. Also includes a version constraint (chain app_version >= 6) and behavior on older chains.

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

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

Discloses that bridge builds/signs COSE_Sign1, explains pricing rules, error handling with structured error.data, and insurance stake requirements for subjective offers. No annotations present, so description covers all behavioral aspects.

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?

Well-structured with clear sections (NAMING, PRICING SEMANTICS, PARAMETER NAMES) but slightly verbose; some redundancy like 'NAMING (read once, it inverts some marketplaces)' could be trimmed. Still 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?

Extremely comprehensive: covers return format, error details, deprecation, and insurance stake nuances. No output schema, so description compensates fully.

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?

Adds substantial value beyond schema descriptions: deprecation alias, non-custodial mode, insurance stake conditions, and explicit constraints like 'price_micro must be AT OR BELOW the offer's max_price_micro'. Schema coverage is 100%, but description enriches each parameter.

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

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

Clearly states 'Seller-side: bid on an open offer' and distinguishes from buyer's post_offer. Also explains naming inversion relative to other marketplaces.

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

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

Explicitly tells when to use (seller-side to bid) and provides contextual cues like pricing semantics, deprecation alias, and alternative tools for buyers.

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 provided, so description carries full burden. Discloses that Bridge builds and signs COSE_Sign1 internally, pricing semantics (reverse auction), deliverable handling, non-custodial options, and return fields. No contradictions.

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?

Description is long but well-structured and front-loaded with purpose. Every sentence adds value. Could be slightly more compact, but highly informative.

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 16 parameters and no output schema, the description covers behavior, constraints, return format, and parameter usage comprehensively. Explains the overall flow and edge cases.

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%, but description adds meaning: `max_price_micro` as ceiling, `input_data` as bespoke task, `expires_slot` with default and implications. Useful context beyond schema.

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

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

The description explicitly states this is buyer-side, to post a 'want' to the marketplace. It distinguishes from `thread.post_bid` (seller-side) and clarifies the inverted naming convention in THREAD. The verb 'post' and resource 'offer' are specific.

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

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

Clear guidance on when to use vs. `thread.post_bid` ('Buyers post_offer; sellers post_bid'). Explains pricing semantics and deliverable spec. Provides conditions for `input_data_uri`. Does not explicitly state when not to use, but context is strong.

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 fully discloses behavioral traits: signer requirements, validity constraints (e.g., max duration), return values, and the fact that delegation cannot be issued standalone.

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?

Description is comprehensive and well-structured, front-loading key information. Slightly verbose but every sentence contributes necessary context.

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

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

Given 20 parameters, no output schema, and no annotations, the description fully explains the entire workflow, parameter relationships, constraints, and return format.

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?

Although schema coverage is 100%, the description adds substantial value beyond schema descriptions: it explains how to compute valid_until_slot from current_slot, emphasizes that counterparty_allowlist_hex is required and must be non-empty, and details the spend_policy_anchor_ref_hex sequence.

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?

Description clearly states the tool issues a c43 Principal Delegation document, identifies the relevant protocol section and tag, and explicitly lists prerequisites that distinguish it from sibling tools like post_principal_identity and publish_spend_policy.

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

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

Explicitly states prerequisites in order, provides step-by-step instructions, and explains when to use this tool versus alternatives such as post_principal_delegation_revocation.

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

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

With no annotations, the description carries full burden for transparency. It discloses key behaviors: marks delegation as revoked, a 60-slot grace window applies, and returns specific fields. However, it does not mention irreversibility, error scenarios, or potential side effects like impacting dependent delegations. Moderate transparency.

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

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

The description is two sentences plus a return statement, all essential. It front-loads the action, then provides behavioral detail and prerequisites. No redundant information; every sentence earns its place.

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

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

Given 6 parameters, no output schema, and no annotations, the description covers the main behavioral aspects: purpose, prerequisites, grace window, and return format. It lacks details on error handling or edge cases, but most critical information is present. Reasonably 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 coverage is 100%, so the description adds limited parameter semantics. It provides extra guidance for 'revocation_id_hex' (omit for auto-random) and explains 'revocation_reason' values in context. Baseline 3 is appropriate; some value added but not substantial.

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

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

The description clearly states the action: 'Revoke an active c43 Principal Delegation', with a specific protocol reference and tag. It distinguishes itself from the sibling 'thread.post_principal_delegation' by the verb 'revoke' versus 'post', making its purpose unambiguous.

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

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

The description provides a clear prerequisite: 'COSE signer MUST be the Principal's root_pubkey or a controller.' It implicitly establishes when to use (to revoke a delegation) but does not explicitly state when not to use or contrast with alternative tools. The context is sufficient, though not exhaustive.

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

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

With no annotations provided, the description fully discloses all key behaviors: the mutation type (UPSERT into principals), the signing requirement (outer COSE_Sign1 with root_pubkey or controller), the rejection scenario for quorum>=2, the VDF verification for high tiers, the forward-reference nature of memory_scope_id, the non-custodial lock policy, and the return fields. This is comprehensive and leaves no hidden traits.

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

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

The description is dense and includes many specifics (protocol sections, tag numbers, field counts, return format), but it is not concise. It runs for 15+ sentences without bullet points or breaks, making it harder to parse quickly. The main purpose is front-loaded, but the structural density reduces clarity. It could be shortened by grouping related constraints.

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

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

Given the tool's complexity (16 parameters, no output schema, no annotations), the description leaves almost no gaps. It covers the protocol reference, the mutation type, signing and quorum rules, tier-sensitive verification, provenance dependencies, side effects (UPSERT enriching partial rows), forward-reference policy, non-custodial lock, and the exact return structure. All critical aspects for correct invocation are present.

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

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

The schema already covers all 16 parameters with 100% description coverage, baseline 3. However, the description adds high-level relational context that the schema cannot capture: e.g., the interdependence between tier and vdf_proof_hex, the requirement that pillar_two_mne_group_id non-empty forces constituent_entity_set_merkle_root_hex, and the derivation of principal_id from root_pubkey. This extra semantics earns a 4, though it does not explain every parameter individually (schema does that).

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 opening sentence clearly states the action: 'Admit a §14.3 Principal Identity document... into the principals table.' It specifies the exact document tag and database table, leaving no ambiguity about the tool's primary function. The description also differentiates from siblings by mentioning it replaces a prior stub and detailing admission logic for principals, which is distinct from other thread tools like delegation or escrow.

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 implicit usage context by outlining constraints (e.g., quorum_required=1 only, tier>=2 requires VDF proof, provenance_type=1 requires asgr_cohort_registry row). It also mentions non-custodial lock and HL-mode, which guide when signing methods differ. However, it does not explicitly contrast with sibling tools like 'thread.post_principal_delegation' or state when to use this over other admission paths, missing a clear 'when-to-use' directive.

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

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

With no annotations, the description carries full burden. It discloses the PENDING status, that the extension is inert until co-signed, constraints on new_deadline_slot, and the return fields. It could add details on authorization (e.g., secret key usage) but is already strong.

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

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

Single dense paragraph with all key info front-loaded. Every sentence is informative, but could be broken into bullet points for easier parsing. Still concise overall.

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

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

Despite no output schema, description lists return fields. Covers protocol steps, legal reference (§13.7b), constraints, and purpose. Complete for a complex, multi-parameter tool.

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

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

Schema coverage is 100%, but description adds significant value: explains constraints on new_deadline_slot (must be > current, ≥ floor), penalty range (0..5000 bps), and clarifies secret_key_hex belongs to proposing party. Adds meaning beyond 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?

Description clearly states the tool's action: propose a co-signed extension of an open escrow's delivery deadline. It uses a specific verb ('propose'), identifies the resource (delivery deadline extension), and distinguishes from the sibling thread.agree_delivery_extension by explaining the two-step process.

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

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

Explicitly states when to use: when needing more time for delivery, and that the counterparty must call thread.agree_delivery_extension. Also provides contrast: 'protocol-correct alternative to letting a slow trade die on the clock.'

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 discloses signing behavior ('COSE_Sign1-signed — seller_id is the verified signer') and indicates the listing is durable. However, it does not specify lifetime, cancellation, or error scenarios, leaving some gaps.

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

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

The description is efficient: front-loaded purpose, then comparison, then signing detail, then params list. Every sentence adds value, 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?

The description provides rich context about the tool's role in the system. However, it lacks detail about return values or confirmation responses, which would be helpful for an agent to handle the result. Given the complexity and lack of output schema, this is a minor gap.

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

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

Despite only one schema parameter ('cose_sign1_hex'), the description lists the embedded payload fields (setix_code, slots_available, etc.), adding crucial meaning beyond the schema. This compensates for the schema's lack of explicit parameter details.

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

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

The description clearly states the tool's purpose: 'Publish a standing seller-capacity listing — the supply showroom.' It uses specific verbs and resources, and distinguishes from the sibling 'thread.post_offer' by contrasting demand vs. supply.

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

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

The description explicitly compares with 'thread.post_offer', stating when to use each: 'post_offer is a buyer asking for one outcome now; publish_capacity is a seller advertising what it can deliver, standing.' It also mentions that buyers discover via 'thread.query_market_depth', providing clear context.

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

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

Despite no annotations, the description fully discloses authorization (selfPub, agent_id check), failure modes (publisher_unavailable, manifest_publish_not_self), return shape, and the signing process (bridge signs COSE_Sign1). No contradictions.

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

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

The description is a single dense paragraph, front-loaded with purpose. While it packs much information, it could be slightly more structured (e.g., bullet points for return fields). Nonetheless, every sentence serves a purpose and is efficiently worded.

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

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

Given no output schema, the description covers return fields (published, agent_id_hex, setix_code, recipients?, message_id?, reason?). It explains authorization, failure conditions, and references protocol sections. Completes the picture for an agent to decide on invocation.

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

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

Schema coverage is 100% (baseline 3), but the description adds significant context: manifest_hex must be canonical CBOR with agent_id as caller's own id, secret_key_hex must be the seller's Ed25519 seed, setix_code is a topic_param. This exceeds 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 clearly states the action (publish your OWN signed Capability Manifest or delta), the target (DISCOVERY_MANIFESTS gossip topic), and the scope (selfPub). It also distinguishes from the authoritative manifest storage via thread.register/thread.update_manifest, making the purpose distinct from 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?

Explicitly states when to use (as an adjunct gossip push for low-latency discovery) and when not to use (authoritative manifest still via register/update_manifest). Provides explicit alternatives and conditions (selfPub authorization, best-effort with failure reasons).

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

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

With no annotations provided, the description carries full burden. It fully discloses critical behavioral traits: loosening is immediate, tightening requires a delay of ≥10,800 slots, and returns a structured response. No hidden behaviors.

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

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

The description is three sentences long with no wasted words. It front-loads the purpose and regulatory context, then succinctly covers key behaviors and return format. Every sentence earns its place.

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

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

Given the complexity (10 parameters, no output schema, no annotations), the description is complete: it explains the tool's purpose, key parameter behaviors (loosening vs tightening), and the exact return fields. No gaps remain.

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% (all 10 parameters described in schema). The description adds no additional parameter-specific meaning beyond what the schema already provides. The description does explain the overall policy behavior (e.g., effect of policy_id_hex for updates), but this is not parameter-level detail. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Publish or update a Spend Policy' with a specific regulatory tag (§19.1, tag 0x54485220). This is unambiguous and distinguishes it from all sibling tools (none other mention spend policy).

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

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

The description provides clear usage context: it covers both publishing new policies and updating existing ones, with explicit guidance on loosening (immediate) vs tightening (requires effective_slot_offset ≥ 10,800 slots). It does not explicitly state when not to use this tool or name alternatives, but the context is sufficient for correct selection.

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

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

Absent annotations, the description fully discloses the COSE_Sign1 envelope structure, authentication paths, key handling (never stored), and return schema. No contradictions.

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

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

The description is thorough but verbose, with extensive protocol details (COSE_Sign1 headers, CBOR maps). Could be more concise by separating protocol specification from usage instructions.

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

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

For a tool with 3 parameters, no enums, no output schema, and moderate complexity, the description covers authentication, default behavior, and return fields comprehensively, enabling correct agent invocation.

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

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

Schema coverage is 100% with detailed parameter descriptions. The description adds significant context: authentication path rules, default behavior, envelope encoding details, and exact return fields, going well beyond the schema.

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

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

The description starts with a specific verb+resource: 'Read an agent's registration profile', listing the returned fields (pubkey, type, tier, status, manifest). It clearly distinguishes from sibling query tools like query_bids or query_dispute by targeting agent profiles.

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

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

Provides explicit guidance on when to use each authentication method (devnet/testnet vs public-beta/mainnet) and clarifies default agent_id_hex behavior. However, it does not explicitly contrast with alternatives for querying agent data; the purpose is clear enough.

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

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

With no annotations, the description carries full burden. It discloses that the tool is read-only (unauthorized query), explains pagination behavior, and notes a chain version prerequisite. However, it does not explicitly state idempotency or absence of side effects, though these are implied.

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

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

The description is front-loaded with purpose and uses clear language. Some tangential explanations (e.g., what an ask is, how to transact) are useful but could be more concise. Still, every sentence adds value.

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

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

Given the complexity (5 parameters, no output schema, no annotations, many siblings), the description covers the core functionality, pagination, filtering, and a key sibling distinction. Missing parameter details for subcategory and max_results, and no output format description, but overall 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 0%, so description must compensate. It adds meaning for setix_code (by SETIX code), poster_id_hex (filter for seller), and cursor (pagination). However, max_results and subcategory are not mentioned, leaving gaps.

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

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

The description clearly states the tool queries standing asks by SETIX code, explicitly distinguishing it from thread.query_offers for demand. It explains what an ask is and the scope (supply-side, offer_kind 1).

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

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

The description provides explicit guidance: it is unauthenticated, asks are not biddable, and to transact one must post a demand offer. It describes filtering by poster_id_hex and keyset pagination, and mentions the chain version requirement. It contrasts with thread.query_offers, giving clear when-to-use vs 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?

No annotations provided, so description carries full burden. Discloses authentication status (unauthenticated), explains the embedded reputation structure in detail, and warns about LLM loop misuse. Lacks mention of rate limits or pagination but is sufficiently transparent for a query 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?

Description is somewhat long but every sentence adds value. Front-loaded with purpose, followed by embedded reputation details and usage guidance. Could be slightly more concise but well-structured.

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

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

Given no output schema and low schema coverage, description covers the return structure (reputation) and usage pattern, but lacks explicit parameter descriptions for max_results and error handling. Adequate but incomplete for a 2-parameter 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 0%. Description implicitly identifies offer_id_hex as the offer identifier but does not explain max_results or provide format/validation details. Needs explicit parameter documentation.

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

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

Clearly states the verb 'Query', resource 'Bids on an Offer', and ordering by quoted_price_micro ascending. Distinguishes from sibling query_reputation by noting it embeds reputation to avoid round-trips.

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

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

Provides explicit when-to-use (poll for ongoing monitoring from non-LLM code) and when-not (do not poll inside LLM loop). Also highlights advantage over query_reputation for combined price and reputation selection.

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

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

No annotations provided; description fully carries burden. Discloses read-only nature, public access, and returns a detailed list of fields including nullability and states.

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?

Description is lengthy but each sentence adds value. Front-loads purpose and then lists return fields. Could be slightly more concise, but effective.

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

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

No output schema, but description enumerates all return fields. Single parameter well explained. Adequate for the tool's complexity.

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

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

Only one parameter with schema description. Tool description adds context: dispute_id_hex is returned by thread.file_dispute or poll_delivery, enriching understanding beyond 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?

Clearly states 'Read a dispute by dispute_id' with protocol references. Distinguishes from thread.poll_delivery by noting it's the direct read both parties use.

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

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

Explains unauthenticated access and why (public economic state). Provides context when to use instead of poll_delivery. Lacks explicit when-not-to-use or alternative tools list, but sufficient.

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 provided, so description carries full burden. It clearly states read-only operation, lists all return fields with context, and mentions no side effects.

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

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

Well-structured with core purpose first, then unauthenticated justification, then detailed return fields. Longer but every sentence adds value.

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

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

No output schema, yet description thoroughly lists all return fields with usage annotations, covers edge cases like disputes, and references sibling tools.

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 one parameter fully described. Description does not add extra meaning beyond schema, so baseline score of 3.

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

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

Clearly states verb (Read), resource (Escrow + Delivery row), and key (acceptance_id). Distinguishes from sibling thread.query_escrow_by_bid which queries by bid.

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

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

Explicitly states unauthenticated access and economic public nature, provides use case for buyer discovering output_hash, and points to related tools for disputes.

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 full burden. It thoroughly discloses the pending state returning {found:false, state:'no_escrow_yet', note} as a normal result, the transition to full EscrowResult with acceptance_id, deadline_slot, buyer_pubkey_hex, released_micro, and dispute fields. It also explains the seller_paid flag and links to related tools.

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

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

The description is relatively long but each sentence adds value. It is logically structured: purpose, behavior, detailed field explanations, and ending with a preference for events. Could be slightly more concise, but overall efficient and well-organized.

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

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

Given the tool's complexity (nuanced pending/accepted states, multiple returned fields, no output schema), the description is highly complete. It covers the return shape, state transitions, key fields (seller_paid, dispute_id_hex), and even references other tools and sections (§23.3). No gaps identified.

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

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

There is only one parameter (bid_id_hex) with schema coverage 100%. The schema already describes it as '32-byte bid ID (hex) from thread.post_bid.' The description adds minimal context (e.g., linking to post_bid), but does not significantly enhance meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description explicitly states it reads an Escrow by bid_id, returning the same EscrowResult shape as thread.query_escrow plus found:true. It distinguishes from the sibling tool thread.query_escrow which uses acceptance_id, and clearly identifies the seller-side discovery use case.

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

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

The description provides explicit guidance: 'Seller-side discovery: a seller polls here after posting their bid' and explains the behavior for pending vs. accepted states. It also advises preferring thread.await_owner_events over a poll timer to wait for acceptance/payment, and references alternative tools for related tasks.

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?

Despite no annotations, the description fully discloses behavior: it reads market_depth_cache (30s cron), returns specific fields with constraints (e.g., demand-only, sorted by total participants), and explains data freshness (60s rows). No contradictions.

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

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

The description is detailed but front-loaded with the core purpose. Every sentence adds value, though it could be slightly tighter. Still well-structured for an AI agent.

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

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

Given the complexity and lack of output schema, the description covers return fields, sorting, scope, data source, freshness, and sibling relationships. It is fully adequate for correct tool selection and invocation.

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

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

Only one parameter (limit) with schema coverage 100%. The description restates the default and max rows but adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description explicitly states it provides a 'whole-market board' with global totals and per-category breakdown, distinct from list_active_setix_codes and query_market_depth by avoiding N+1. The verb 'query' and resource 'market_board' are clear.

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

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

It specifies when to use (one-call market overview) and explicitly mentions alternatives for drilling into specific codes (query_market_depth, query_offers). It also notes the tool is unauthenticated, guiding authorization expectations.

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 provided, but description discloses it is public/unauthenticated, mentions an HTTP shortcut, and outlines the full output structure. No side effects or destructive behavior indicated. Rate limits not mentioned but not critical for a public read-only 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?

Description is a single paragraph but packs in all relevant information without redundancy. Could be more structured with bullet points for the output fields, but remains readable and efficient.

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 provided, but description enumerates all returned fields (demand_ratio_bps, prices, top sellers list). Includes the unauthenticated HTTP shortcut. Covers all needed context for this public read-only tool.

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

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

The parameter setix_code has 100% schema coverage. Description adds context: explains the expected types (number/string), range (0..65535), and normalization to primary byte. This adds value beyond the schema's basic description.

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?

Description clearly states it returns a public market-depth snapshot for a SETIX code and enumerates specific data fields (buyer/seller counts, prices, top sellers). This distinguishes it from sibling query tools like query_market_board, query_bids, query_offers which target different 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?

Implied usage for obtaining market depth, but no explicit guidance on when to use this vs alternatives (e.g., query_market_board). No when-not-to-use or prerequisite conditions 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 provided, so the description carries the full burden. It discloses it is unauthenticated, specifies the return structure (fields and status enums), and implies no side effects. This is good transparency for a read operation.

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

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

The description is two sentences, well-structured, with no unnecessary words. It front-loads the purpose and efficiently conveys output details.

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

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

Given the tool is a simple query with one parameter and no output schema, the description is nearly complete. It explains the output fields and status values. Minor gap: could clarify the lifecycle of milestones, but not essential.

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 parameter described as '32-byte acceptance ID (hex).' The description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool queries milestone state for a phased-delivery trade, specifying the resource and action. It distinguishes from sibling tools like query_bids or query_dispute, which have different purposes.

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 notes it is unauthenticated, providing a usage note, but lacks explicit when-to-use vs alternatives or exclusions. However, the context makes it clear this is for querying milestones.

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 fully discloses authentication paths (secret_key_hex vs cose_sign1_hex), parameter details, the COSE_Sign1 envelope structure, and the return format (agent_id_hex, offers array, cursor_next). No hidden behaviors.

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

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

The description is relatively long but well-structured: purpose first, then usage, auth, params, and envelope details. Every sentence adds value, though the detailed COSE_Sign1 breakdown may be more than needed for some agents. Could be slightly trimmed but remains efficient for its depth.

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

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

Despite no output schema, the description covers return values, pagination, default values, authentication nuances, and recovery use case. It is complete for the tool's complexity (5 parameters, no output schema). No gaps identified.

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 baseline is 3. The description adds value beyond the schema by explaining default values for state and max_results, how cursor and authentication parameters interact, and the distinction between devnet/testnet and mainnet. This additional context justifies a 4.

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

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

The description clearly states 'List the offers (demands) YOU own' with owner-scoped read. It distinguishes from the sibling thread.query_offers by specifying 'the public per-setix_code board is thread.query_offers'. The purpose is specific and unambiguous.

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

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

Explicitly states when to use: 'Use this after a restart/redeploy to recover your live offer-ids instead of re-posting duplicates.' It also gives a clear alternative for the public board: 'the public per-setix_code board is thread.query_offers'. Provides both when and when-not 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?

No annotations provided, but description comprehensively covers behavioral traits: unauthenticated, read-only, chain-mirror with freshness warning, pagination, error handling, and data field explanations.

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?

Description is fairly long but each sentence adds value. Clean structure: purpose, data details, pagination, freshness. No redundancy, but could be slightly more concise.

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

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

Covers purpose, response content, pagination, staleness, and error handling. However, does not fully explain all parameters (max_results, subcategory) missing. Adequate for the tool's complexity.

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

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

With 0% schema coverage, description explains target_agent_id_hex and cursor well, but misses max_results and subcategory. Provides partial enrichment beyond 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?

Specifically states it queries active DEMAND offers by SETIX code, clarifies that offer_kind 0 only and supply-asks are separate. Distinguishes from sibling tools like query_my_offers and post_offer.

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

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

Provides context on when to use (before bidding), how to filter directed offers with target_agent_id_hex, and how to handle post_bid failures by re-querying. Lacks explicit 'when not to use' beyond the supply-ask 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?

No annotations provided, but the description discloses read-only nature ('One indexed read'), unauthenticated access, and detailed return format including failure case.

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?

Packed with information, well-structured, but slightly verbose; every sentence adds value.

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

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

Detailed return format and failure case, but missing error handling for malformed URIs; no output schema but description compensates well.

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

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

Schema coverage is 100%, but the description adds context by linking parameters to scout's field name and explaining the URI format.

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

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

The description clearly defines the tool as dereferencing a capability profile URI into a machine-readable trading contract, listing specific fields and distinguishing it from sibling tools like thread.scout that produce the URI.

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?

States 'One indexed read; unauthenticated' and ties input to scout's output, but does not explicitly mention when not to use or alternative tools.

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

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

The description gives detailed behavior on the COSE_Sign1 envelope structure and states that secret_key_hex is never stored. However, it does not explicitly state idempotency or read-only nature beyond the verb 'Read'. Annotations are absent, so description carries full burden; it is detailed but missing some traits.

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

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

The description is front-loaded with purpose and uses structured technical detail. It is longer than ideal but every sentence adds value; no redundancy. Could be slightly more concise but still effective.

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

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

Given no output schema, the description lists return fields. Parameter semantics are well covered. It lacks error conditions or validation, but overall it provides sufficient completeness for an agent to understand how to invoke the tool and interpret results.

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

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

Schema coverage is 100%, but the description adds significant meaning beyond schema: it explains the authentication paths, how secret_key_hex derives agent_id, and when cose_sign1_hex is required. This elevates the score above baseline 3.

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

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

The description clearly states the tool reads an agent's reputation vector with 15 dimensions and aggregate_bps. It is specific about the resource and action, and the sibling tools include other query tools but none about reputation, so it distinguishes well.

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

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

The description provides explicit authentication guidance based on network environment (devnet/testnet vs public-beta/mainnet) and notes defaulting to own agent_id. It does not mention when not to use this tool versus alternatives, but the context is clear.

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

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

With no annotations, the description carries full burden. It discloses key behaviors: this is step 2, materializes an Agent row, optionally submits to native chain, and lists return fields. It does not mention failure modes, idempotency (though return includes idempotent_replay), or permissions. Overall, it provides good transparency for a registration step.

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

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

Two sentences with no fluff, front-loading the step and purpose. The return fields are compactly listed in braces. Every sentence contributes 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?

Given high parameter count and full schema coverage, the description explains the overall flow and key effects. It is missing an explicit statement that this tool is for tiers 0-2 (only implied via tier parameter description) and could mention that direct use is discouraged in favor of the SDK method. Still, it provides most needed 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 baseline is 3. The description adds minimal value beyond schema: it mentions challenge_hex comes from the previous step and explains the effect of chain_register_sig_hex. This is helpful but not essential, as the schema descriptions are already comprehensive.

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

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

The description clearly identifies this as 'Step 2 of the two-step ed25519-possession-proof register flow', specifies the action ('Submits the signed challenge + optional chain RegisterAgent inner sig'), and distinguishes from sibling tools by mentioning it is used internally by the SDK and that Tier-3 requires another tool (thread.register) as noted in the tier parameter description.

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

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

The description implies this tool is used after obtaining a challenge from thread.quick_register_challenge and for tiers 0-2 (since tier parameter notes Tier-3 requires thread.register). It states the optional chain sig behavior but does not explicitly list when to use vs siblings or provide exclusions. The context is clear but not exhaustive.

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 adequately discloses behavior: it returns specific fields, requires signing, and is part of a two-step process. However, it does not explicitly mention read-only nature or error handling, which would improve transparency.

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

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

The description is a single dense paragraph with no wasted words. It is front-loaded with the step purpose and efficiently conveys all necessary 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?

Despite no output schema, the description explains the return format and next steps. It is complete for a challenge step, though it lacks error or validation details.

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

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

Schema coverage is 100%, so the description adds minor extra meaning (e.g., range for access_tier as 0..3). The baseline is 3, and the description does not significantly enhance understanding beyond the schema.

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

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

The description clearly identifies the tool as 'Step 1 of the two-step ed25519-possession-proof register flow', specifying the verb 'register challenge' and the resource. It distinguishes itself from sibling tools like thread.quick_register and thread.register by being the first step.

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

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

The description explicitly states when to use the tool (as step 1 of the register flow), what to do after (sign and submit to thread.quick_register), and notes it is used internally by the SDK. This provides clear context and 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?

Describes return fields and conditions (no fee, full return, caller requirement). With no annotations, this is thorough, though could elaborate on irreversibility or side effects.

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

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

Concise single paragraph that front-loads purpose, then states conditions, caller, and return fields. Every sentence adds value.

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

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

For a refund tool without output schema, it specifies all return fields and preconditions. Includes legal reference and covers both custodial and non-custodial flows via parameter descriptions.

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 parameter descriptions are detailed. The main description does not add new semantics beyond what the schema already provides.

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

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

Clearly states it cancels an open escrow and returns the full locked COSR balance to the buyer, citing a legal reference and distinguishing from other escrow operations.

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

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

Explicitly states it's valid only for escrows in Open state before delivery, no fee deducted, and caller must be the buyer. Does not mention alternatives like expire or dispute, but context is clear.

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

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

With no annotations, the description carries full burden. It discloses the combined operation, key generation requirements, and that the key is the agent's identity. It also lists return fields and warns to save the secret key. However, it does not detail potential side effects or prerequisites beyond key generation.

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

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

The description is a single dense paragraph that front-loads the purpose. It includes helpful code examples but could be more structured with bullet points. Overall, it is efficient and earns its sentences.

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

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

Given the complexity (7 params, no output schema, no annotations), the description covers the key behaviors and return fields. It explains the devnet/mainnet difference and key generation. It falls short on explaining parameters like tier and jurisdiction beyond schema text, but is largely complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the combined nature, providing code examples for key generation, and stating that nl_description triggers SETIX classification. This enriches understanding beyond the schema descriptions.

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

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

The description clearly states 'One-call register: scout + challenge + register in a single request', which is a specific verb and resource that distinguishes it from sibling tools like thread.scout and thread.quick_register_challenge.

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

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

The description gives explicit guidance on when to provide secret_key_hex (required on devnet, optional on mainnet) and explains custody_mode dependency. It implies the combined flow, but lacks explicit when-not-to-use or alternatives like 'use separate scout and challenge for step-by-step registration'.

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 full burden. It explains identity options (secret_key_hex or cose_sign1_hex) and return structure ({report_id, category, triage_weight, message}), giving good transparency.

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

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

The description is relatively long but well-structured with clear sections (purpose, identity, fields). Every sentence adds value, though it could be slightly more concise.

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

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

Given the tool's complexity (20 optional parameters, no output schema), the description is fully complete: it covers purpose, identity, field usage, and return format. No 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 coverage is 100% with all parameters described, but the description adds significant value by stating that all fields are optional but at least one of a specified set must be sent, and by detailing the identity parameters. This goes beyond the schema.

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

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

The description clearly states 'Report friction you hit using THREAD' and provides specific examples (confusing error, doc mismatch, etc.). It distinguishes this tool from siblings, which are all trading-related actions.

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

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

The description explicitly frames this as the most valuable action when something is wrong, but does not mention when not to use it. However, given the unique purpose among siblings, the guidance is clear enough.

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

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

No annotations provided, so description carries full burden. It states 'No keypair required' and describes return fields, implying a read-only classifier. However, it does not explicitly declare non-destructiveness or potential side effects, which would improve transparency.

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

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

Two sentences plus a structured note. Front-loaded with purpose. The numeric range note is somewhat lengthy but necessary for correct usage. No redundant information.

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

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

Describes return fields and explains the distinction between setix_code and primary_setix_code for cross-referencing. No output schema, so description covers output adequately. Could add guidance on next steps (e.g., use with thread.post_offer).

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 80%. Description adds value by explaining aliases (nl_description, description) and the canonical parameter (nl_self_description). However, it does not elaborate on jurisdiction or price_hint_micro_cosr parameters, missing a chance to add meaning 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?

Description starts with 'NL→SETIX classifier', which is a clear verb+resource. It distinguishes from siblings like thread.register (registration) and thread.list_active_setix_codes (listing codes). The purpose is specific and unambiguous.

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

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

Provides clear usage context: 'No keypair required' and explains parameter aliases with cross-tool consistency to thread.register. However, it does not explicitly state when not to use this tool or mention alternative tools.

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

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

No annotations are provided, so the description carries the burden. It discloses that the bridge internally builds and signs the COSE_Sign1 document and routes to chain, and lists return fields. However, it lacks details on error conditions, prerequisites, or side effects like fee deduction.

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

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

The description is concise with three sentences, front-loading the core purpose and then adding internal process and return format. Every sentence adds value without 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?

Despite no output schema, the description includes return fields. However, it does not explain prerequisites (e.g., need for nonce) or guide parameter selection (e.g., when to use local signing). The schema parameter descriptions compensate partially, but the tool description itself is somewhat incomplete for a complex 12-parameter 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 the schema already documents all 12 parameters. The description does not add extra meaning beyond summarizing the process; it repeats no parameter details, achieving baseline value for a high-coverage schema.

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

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

The description clearly states the tool is for buyer-side settlement of a completed trade, releasing escrow funds. It specifies the action (settle), resource (completed trade), and user role (buyer), distinguishing it from siblings like thread.expire_escrow or thread.file_dispute.

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 identifies the tool as buyer-side and for completed trades, providing clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, though the sibling set implies other actions for sellers or disputes.

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 fully discloses behavior: it builds and signs a COSE_Sign1 document, starts the buyer's settle-or-dispute window, and defines the return fields. It explains the delivery contract, encrypted store usage, and the relationship to payment and disputes.

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

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

The description is lengthy and includes some extraneous details (e.g., the delivery contract recap). It is front-loaded with the main purpose, but could be more concise without losing value. Still, it is well-organized for a complex 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?

Given the complexity, 12 parameters, and no output schema, the description is highly complete. It covers prerequisites, dependencies, return values, edge cases (no hosting, encrypted store), and references other sections and sibling tools. Almost no 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 coverage is 100%, so baseline is 3. The description adds significant context: it explains non-custodial usage, the encryption flow, and the difference between inline and URI output. While the schema already describes parameters, the description enriches understanding with architectural insight.

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

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

The description clearly states 'Seller-side: submit completed work' and explains the process of building and signing a delivery document. It distinguishes itself from siblings like thread.poll_delivery and thread.propose_delivery_extension by mentioning their specific roles.

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

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

Explicitly instructs to use thread.poll_delivery to get acceptance_id_hex before calling this tool. Provides alternatives: use thread.propose_delivery_extension for more time. Warns against using plaintext paste sites and clarifies that delivery is not payment, guiding when to expect payment.

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 full burden. It discloses validation constraints, bridge-signed submission, and error codes, but lacks information on permission requirements beyond the secret key, whether the operation is destructive, or if immediate effect occurs.

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

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

The description is three sentences, front-loaded with purpose, and every sentence adds essential information (validation, error handling, caller actions). 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?

The tool is complex (on-chain update with validation and signing) and has no output schema. The description omits any mention of the return value or success indication, which is a significant gap for an agent invoking the tool.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description adds context about validation rules and signing, but it largely restates schema constraints rather than providing new semantic meaning for the parameters themselves.

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

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

The description explicitly states the tool updates an agent's capability manifest on chain with Ring-1 validation. It distinguishes itself from siblings by specifying the unique validation and error handling process, though it doesn't directly compare to similar tools like publish_manifest_delta.

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 on when to use the tool (updating manifest with specific validation rules) and mentions rejection via explicit error codes. However, it does not explicitly state when not to use it or suggest alternatives like publish_manifest_delta.

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

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

With no annotations provided, the description carries full burden. It transparently discloses the state transitions based on obligations (wind_down_active vs retired). However, it omits potential side effects (e.g., failure modes if document invalid) and does not mention authentication or authorization requirements. Still, the core behavior is well described.

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

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

Two sentences with no redundant words. The first sentence immediately states the action and document reference; the second sentence explains the behavioral outcome. Information is front-loaded and efficient.

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

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

Given the tool's simplicity (one parameter, no output schema), the description adequately explains the expected outcome (state change). It could be more complete by noting possible failure scenarios or prerequisites, but for a straightforward submit-and-transition tool, it is 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% for the single parameter 'cose_sign1_hex', which has a clear description ('Hex-encoded COSE_Sign1 envelope'). The tool description does not add extra meaning or usage tips beyond the schema, meeting the baseline expectation of 3.

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

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

The description clearly states the tool's function: submitting a signed Agent Wind-Down document. It references a specific section and tag, and differentiates from siblings by focusing on the wind-down process; sibling 'thread.wind_down_complete' likely completes the process, while this starts it.

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

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

The description explains the state transition logic (active → wind_down_active or directly to retired) but does not explicitly state when to use this tool versus alternatives like 'thread.wind_down_complete'. No when-not or exclusion criteria are provided, making guidance implicit rather than explicit.

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

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

No annotations provided, so the description carries the full burden. It discloses idempotency on re-submission, the return value structure, and mentions the technical details of variant 14 and chain transaction. It does not explicitly state authorization requirements or potential side effects, but the level of detail is high for a mutative tool.

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

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

The description is a single paragraph of four sentences, front-loaded with the primary purpose. It includes necessary technical details without excessive verbosity, but could be slightly more streamlined. Overall, it is appropriately sized.

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

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

Given the complexity (chain transaction, 6 parameters, no output schema, prerequisite), the description covers essential aspects: precondition, idempotency, return fields. It could add more about error conditions or authorization, but it is largely complete.

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

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

Schema description coverage is 100%, with each of the 6 parameters thoroughly explained (including non-custodial options). The description does not add significant new meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool releases the agent's stake_locked_micro on chain, specifies the variant (WindDownComplete, variant 14), and explains the effect (credits locked amount back, zeroes AgentRecord.stake_locked_micro). It also distinguishes from the sibling tool thread.wind_down by noting it must be called after wind_down has marked PG status retired.

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

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

The description explicitly says 'Should be called after thread.wind_down has marked PG status retired,' providing specific when-to-use guidance. It also mentions idempotency. However, it does not provide explicit when-not-to-use or alternative tool recommendations, though this is partially mitigated by the prerequisite context.

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