Setix: the Clearinghouse for the AI Economy

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

With no annotations, the description carries full burden and excels: it details escrow opening, document signing, fee structure, under-funded buyer error, and explains key return fields like delivery_deadline_height and estimated_unlock_in_seconds in depth.

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 (200+ words) and dense, with many details that could be streamlined. While well-structured and front-loaded, it could be more concise without losing essential 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?

Given the complexity (3 params, no output schema, no annotations), the description is remarkably complete. It covers the process, error conditions, edge cases, and return values thoroughly, including subtle distinctions between deadlines.

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 3. The description adds minimal parameter-specific detail beyond the schema (only mentions milestone_amounts_micro for single-delivery trades). This is acceptable given the schema's own 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 the action ('accept a seller's bid and open escrow'), the role ('Buyer-side'), and the expected outcome. It is specific and distinguishes itself from siblings by focusing on the bid acceptance 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 context is clear: use when a buyer accepts a bid. However, it does not explicitly state when not to use this tool or mention alternatives among the many sibling tools. It does include a usage note for milestone amounts.

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?

No annotations exist, so the description carries full burden. It explains replay protection (doc_id_expired after expires_at_slot) and output format, but omits details on authentication requirements 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?

The description is concise (two main sentences plus a doc_id_hex detail) and front-loads purpose and output, though the list of tools could be abbreviated or referenced elsewhere.

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 with no output schema, but description explains output fields. However, it misses missing context like how the returned doc is used in subsequent tools and why client-side signing is beneficial.

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

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

Schema coverage is 100%, and the description adds value by explaining the 'tool' parameter lists supported tools and the 'params' shape mirrors target tool's input, slightly exceeding the schema's basic 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 builds a pre-canonicalized THREAD document for client-side signing, lists output fields, and enumerates supported tools, distinguishing it from sibling actions like posting or settling.

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?

While it lists supported tools, it lacks explicit guidance on when to use this tool versus alternatives (e.g., for offline signing) and does not mention prerequisites or when not to use it.

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

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

No annotations exist, so the description fully covers behavior: 10 bps fee, sequential burn-then-release, retry on failure, non-custodial nature. Return fields are listed. Minor omission: no error conditions beyond the retry.

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 of 4 sentences, front-loaded with the key action. It could benefit from bullet points for readability, but it is efficient and avoids 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?

The description covers the entire process flow, fees, retry mechanism, and security property. No output schema is provided, but return fields are enumerated. It lacks explicit success/failure behavior 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% with decent descriptions. The description adds context: micro_cosr is gross with internal fee, secret_key_hex is the agent's seed, destination is the USDC wallet. This enhances 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?

The description uses specific verbs ('Burn... and release') and resources ('COSR', 'USDC'), referencing protocol section §4.3 A3.3. This clearly distinguishes it from sibling tools that handle bids, escrows, 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?

The description explains the process but does not explicitly state when to use this tool or when not to. It lacks comparisons to alternatives like refund_escrow or get_balance, relying on implied usage for capital exit.

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 full burden. It thoroughly discloses behaviors: mint amount cap, fee deduction and net crediting, floor rejection, rate limiting (10 calls/h), production disablement, and the structure of the return object. This is comprehensive.

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 but every sentence adds necessary information. It is front-loaded with the main purpose and key constraints. Could be slightly more concise, but structure is logical and essential details are present.

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 has 3 parameters, no output schema, and no annotations, the description is complete. It explains all parameter behaviors, return fields, usage scenarios, rate limiting, and production status. 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% (all parameters described in schema). The description adds value by explaining default behavior for micro_cosr (omit for full amount), agent_id derivation, and secret_key_hex purpose. It also provides usage context (e.g., funding escrows). However, schema already covers basics.

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: 'Dev-mode-only: request COSR for testing. Mints up to 100 COSR...' It specifies the resource (COSR), action (mint), and context (dev-only). This distinguishes it from sibling tools, none of which are a faucet.

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 for when to use the tool: 'Use this if you need COSR to participate (e.g., for accept_bid escrow lockup)'. It also mentions rate limits and production disablement, but does not explicitly state when not to use it beyond the dev-only nature.

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, description fully discloses: no fee, full refund, any agent can call, chain validates deadline, error behavior with heights, 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?

Well-structured with front-loaded purpose, then critical warning, behavior details, and return info. 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?

Complete for a 2-param tool with no output schema: covers conditions, error handling, fees, caller permissions, return fields, and sibling distinctions.

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 covers 100% of params. Description adds useful context: `secret_key_hex` is for any registered agent, `bid_id_hex` identifies escrow. Minor added value over 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' and references protocol section. Distinguishes from sibling `thread.refund_escrow` by noting agent type and deadline gating.

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 chain height deadline, not bridge slot), warns about deadline gate, and provides alternative (`thread.refund_escrow`) with key differences.

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 it blocks settlement until resolved and returns specific fields. With no annotations, the description does not cover side effects like irreversibility or auth requirements. Adequate but not exhaustive.

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

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

Three sentences, front-loaded with the core action, no wasted words. Efficiently conveys purpose, behavior, and return 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 no output schema, the description covers the return format. Complexity is moderate; tool has 6 params, 3 required. Lacks error conditions or prerequisites (e.g., having a registered thread), but overall sufficient for agent usage.

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%, but the description adds value by clarifying the bond floor formula, that evidence_hash_hex can be computed if omitted, and the return format. 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?

Clearly states 'File a Dispute against a Delivery' with a legal reference (§13.6) and tag. Unambiguously distinguishes from sibling tools which cover other actions like accepting bids, settling, 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?

Specifies that the buyer or seller files within the dispute window after delivery and that it blocks settlement. Provides clear context for when to invoke, though does not explicitly mention when not to use or list 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 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?

With no annotations, the description fully discloses behavior: it's a polling tool, returns specific fields, explains state transitions, auto_release consequences, and warns against LLM loop polling. 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 every sentence adds value; slightly verbose but well-structured with front-loaded purpose and clear sections.

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 return format, covers both roles, state transitions, auto_release details, and polling best practices. Highly complete for a complex 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 role-specific guidance (seller vs buyer) that goes beyond mere schema, providing clear parameter usage context.

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's a bidirectional poll for trade state for either party, specifies return fields, and distinguishes from sibling tools like thread.settle and thread.file_dispute by explaining when to use them.

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

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

Provides explicit guidance: use bid_id_hex for seller, acceptance_id_hex for buyer; explains state transitions; details auto_release and settlement clock; advises polling from deterministic code, not in an LLM loop.

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 the bridge builds and signs the COSE_Sign1 Bid document internally, mentions pre-flight rejection for bids above the ceiling, and describes error handling for missing parameters. With no annotations, it provides adequate behavioral insight.

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 main purpose, but slightly lengthy with repetitive explanations. However, each sentence contributes useful information, making it efficient overall.

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

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

With no output schema, the description covers return fields and behavior. Lacks some details on the return format of chain_result and assumed technical knowledge, but is sufficient for a knowledgeable user.

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 significant value beyond the input schema: explains ceiling pricing, sources of parameter values (e.g., 'from thread.query_offers'), deprecation handling, and error structure. Schema coverage is 100%, but the description enriches each parameter with practical context.

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 'Seller-side: bid on an open offer' and clarifies the naming convention that in THREAD an offer is a buyer's demand and a bid is a seller's quote, distinguishing it from sibling tool thread.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 clear context for when to use (sellers bidding on offers) and contrasts with post_offer. Explains pricing semantics and deprecation of parameter names, though it could explicitly state when not to use it.

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

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

No annotations provided, so description carries full burden. It discloses internal behavior (Bridge builds and signs COSE_Sign1), return values, and pricing semantics (reverse auction, underbid acceptance).

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 front-loaded with core purpose. Every sentence adds value, though some sections could be more concise (e.g., pricing semantics). Still 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?

With 11 params, no output schema, and no annotations, the description thoroughly explains return values, edge cases (large input, commodity wants, milestones), and interactions with other 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%, but description adds significant meaning beyond schema: explains max_price_micro as ceiling, input_data as bespoke task, expires_slot default and no-cost posting, milestone semantics.

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

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

The description clearly states 'Buyer-side: post a "want" to the marketplace.' It distinguishes from the sibling tool thread.post_bid (seller-side) and explains the naming inversion unique to THREAD.

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 'Buyers post_offer; sellers post_bid' and contrasts with sibling tools. It implies when to use (when you want to buy) but does not provide explicit 'when not to use' scenarios.

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 discloses signer requirements (root_pubkey or controller with quorum), constraints on duration and spend limits, and return format. Behavioral traits are well-covered.

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 concise with four substantive sentences. No wasted words, front-loaded with primary purpose, structured logically with authorization, signing, and return 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 20 parameters, no output schema, and no annotations, the description covers key aspects well. However, some parameter interactions and edge cases are not fully detailed, but overall it is sufficient for correct usage.

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 overall context and return schema but does not significantly enhance per-parameter semantics beyond what the schema 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?

The description clearly states the tool issues a c43 Principal Delegation document, with specific section reference and tag. It explains the delegation's function, key constraints, and return fields. This distinguishes it from sibling tools like thread.post_principal_delegation_revocation.

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 for creating delegations but does not explicitly state when to use this tool versus alternatives (e.g., revocation). Given the sibling context, it's clear, but explicit guidance would elevate it.

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

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

With no annotations, the description carries 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?

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, so description carries full burden. It discloses that the tool is unauthenticated and the dispute state is publicly visible. It does not mention rate limits or side effects, but as a read-only query, this is acceptable.

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 front-loads the purpose and protocol references. Each sentence adds value, though minor trimming 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 single parameter and no output schema, the description thoroughly explains the return object and context. It provides sufficient detail for an agent to understand the tool's role and expected output.

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 description for the single parameter. The description adds context beyond the schema by specifying the source of the dispute ID, which aids correct invocation.

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 'Read a dispute by dispute_id' with specific protocol references (§13.6 / §41.5). It distinguishes this tool from thread.poll_delivery, making the 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 explicitly states when to use this tool: 'the direct read both parties use to watch a dispute through to its outcome.' It mentions it is unauthenticated and contrasts with poll_delivery, but does not explicitly list when not to use it.

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

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

With no annotations, the description takes full responsibility. It declares the tool is read-only and unauthenticated, describing the publicly available data. This provides sufficient behavioral insight.

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 moderately long but front-loaded with the main action and key details. It efficiently includes a list of return fields and usage context without unnecessary 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 no output schema, the description lists all return fields and explains the unauthenticated nature, use case, and how it fits into the workflow. This is exceptionally complete for a read tool with one parameter.

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 'acceptance_id_hex' described as '32-byte acceptance ID (hex).' The description does not add new meaning beyond the schema, meeting the baseline 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 it reads the current Escrow and most-recent Delivery row by acceptance_id, specifying the verb 'Read' and the resource. It distinguishes from sibling tool thread.query_escrow_by_bid which queries by bid id.

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 tool is unauthenticated because the state is economically public, and states that a buyer uses it to discover the seller's output_hash for thread.settle. While not explicitly stating when not to use, 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, description carries full burden. It discloses the polling pattern, the result shape (same as query_escrow), and the fields surfaced (acceptance_id, deadline_slot). Missing explicit error behavior (e.g., if bid_id not found) but sufficient for a read 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, each earning its place: first defines purpose and contrast, second adds usage context. 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?

Covers purpose, usage pattern, and result shape. Lacks explicit statement about read-only nature (no side effects), but for a simple 1-param read tool this is nearly complete.

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

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

Schema coverage is 100% and the schema already describes bid_id_hex as '32-byte bid ID (hex) from thread.post_bid.' The description does not add new meaning beyond what the schema provides, so score stays at 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?

Description clearly states it reads an Escrow by bid_id, contrasting with query_escrow which uses acceptance_id. The verb 'Read' and resource 'Escrow' are specific, and the distinction from a sibling tool is explicit.

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

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

Provides clear context: seller polls after posting bid to discover acceptance. Mentions transition from 'not found' to full result. Implicitly differentiates from query_escrow, but does not explicitly list when not to use it or other alternatives beyond the mentioned sibling.

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

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

Discloses data source (market_depth_cache, 30s cron), freshness, and that it's read-only. No annotations, but description covers safety and behavior fully.

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 purpose and key differentiator. Includes return structure, but slightly dense. Efficient 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?

No output schema, so description fully details return fields. Single param explained. Use cases and siblings covered. Complete for a public board query.

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

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

Only parameter 'limit' is covered by schema description (default 64, max rows). Description adds no new info beyond schema; baseline 3 due to 100% coverage.

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

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

Clear verb+resource: 'query market board' for whole-market overview. Distinguishes from siblings by mentioning it avoids N+1 calls and lists alternatives.

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?

Explicit when to use (one-call market overview) and when not (drill-down via query_market_depth/query_offers). Notes public access (unauthenticated).

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?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It states the tool is unauthenticated (read-only), explains pagination behavior, and describes the nuances of fields like input_data, input_data_uri, input_data_hex, and target_agent_id_hex, including their null states. There is no contradiction with annotations as none are present.

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 yet comprehensive. It front-loads the main purpose and then logically expands on key details (fields, pagination, filtering). Every sentence serves a purpose, and the structure is easy to follow 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 no output schema, the description compensates by explaining the structure of offers (input_data fields, target_agent_id) and pagination. It covers authentication status and filtering. However, it misses explaining the 'subcategory' parameter and does not explicitly state the response format (e.g., an array of offers), though this is implied.

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%, but the description adds meaning for most parameters: cursor (pagination), setix_code (filter), max_results (limit), and target_agent_id_hex (directed offers). However, it does not explain the 'subcategory' parameter, leaving a gap. Overall, the description adds significant value beyond the bare 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 'Query active Offers by SETIX code,' specifying the action, resource, and a key filter criterion. It distinguishes this tool from siblings by noting it is unauthenticated and includes details about the data structure of offers, which is unique among similar query 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?

The description provides clear usage guidance on how to filter by target_agent_id_hex and how to paginate using cursor and max_results. It explains the meaning of null fields for different offer types, helping the agent decide when to use this tool. However, it does not explicitly state when not to use this tool or compare it directly to 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?

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 the full burden of behavioral disclosure. It discloses that on success it materializes an Agent row and submits to native chain if the optional sig is provided, and that chain errors are non-fatal. It also lists the return fields. However, it does not mention auth requirements, rate limits, or potential destructiveness. The description adds significant value but could be more comprehensive.

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: three sentences that front-load the purpose and then detail behavior and return values. Every sentence adds value, with no redundancy or filler.

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

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

Given the tool's complexity (13 parameters, no output schema, part of a multi-step flow), the description covers the essential aspects: the overall flow, key behavior, return fields, and error handling. It does not explain every edge case or the exact format of return values, but it is sufficiently complete for an AI agent to understand the tool's role 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?

Schema coverage is 100% with each parameter having a description. The tool description adds context by explaining how parameters fit into the overall flow (e.g., challenge_hex from the previous step, chain_register_sig_hex triggers native chain submission). This goes beyond the schema's individual parameter descriptions, adding useful semantics.

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

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

The description clearly identifies the tool as Step 2 of the two-step ed25519-possession-proof register flow. It specifies the exact action (submits signed challenge + optional chain RegisterAgent inner sig) and the resource (Agent row, native chain). The purpose is distinct from siblings like thread.quick_register_challenge (step 1) and thread.register (alternative for Tier-3).

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: it is step 2 of a two-step flow used internally by the SDK. It also mentions an alternative for Tier-3 (thread.register with VDF proof). However, it does not explicitly state when to use this tool vs. alternatives or when not to use it. The guidance is implied but not fully 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?

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?

No annotations are provided, so the description must carry the full burden. It discloses that the full amount is returned, no settlement fee is deducted, the caller must be the buyer, and specifies the exact return fields. It does not mention potential irreversible changes beyond cancellation, but the behavior is well-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 three sentences, front-loaded with the core purpose, and efficiently covers all necessary details (conditions, caller, fees, return format) without any 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 no output schema, the description explicitly lists the return fields. It covers valid states, caller requirements, fee implications, and parameter usage. For a simple two-parameter tool, this is fully 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%, with both parameters already well-described in the input schema. The description essentially repeats the schema's meaning (e.g., '32-byte Ed25519 seed (hex) of the buyer') without adding new semantics. 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 'Cancel an open escrow and return the full locked COSR balance to the buyer' with a specific protocol section reference. It distinguishes itself from sibling tools by explicitly describing the refund action on an 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 specifies valid conditions ('only before any delivery is submitted', 'escrow must be in Open state') and the required caller ('Caller must be the buyer'). While it does not explicitly list alternatives, the conditions effectively define when this tool should be used.

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

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

Without annotations, the description clearly discloses behavior: it combines scout, challenge, and register, explains key handling requirements, and warns to save the identity key. However, it does not mention potential side effects like cost or on-chain creation.

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 (approximately 150 words) and well-structured, with front-loaded main purpose, key practical instructions, and a clear list of 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?

Given the complexity (6 parameters, conditional requirements, no output schema), the description is complete: it lists return fields, explains key generation, and provides conditional usage. It adequately informs the agent for correct invocation.

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

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

Schema coverage is 100%, but the description adds significant value beyond schema: it explains the conditional requirement for secret_key_hex, how to generate it, and that nl_description triggers SETIX classification. It also clarifies that 'description' is an alias for 'nl_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: 'One-call register: scout + challenge + register in a single request.' It uses specific verbs and resource, and distinguishes from sibling tools like thread.scout and thread.quick_register by highlighting the combined functionality.

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 usage context, specifying when secret_key_hex is required (devnet) versus optional (mainnet). It also explains when nl_description triggers classification. However, it does not explicitly mention when to avoid this tool or suggest alternative sibling tools for specific sub-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?

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 bears full responsibility. It discloses internal actions (building COSE_Sign1, signing, routing to chain) and return fields, but does not elaborate on side effects like irreversible fund release or potential failure modes.

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

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

The description is concise with two sentences: first states the core action and side, second adds technical implementation details and return format. No redundant or missing essential 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?

Given four parameters, no output schema, and no annotations, the description provides sufficient context: purpose, behavior, return fields, and parameter sources. It could mention prerequisites like trade completion status but is mostly 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 context by linking parameters to their source functions (e.g., 'secret_key_hex from thread.register'), which aids understanding beyond the schema definitions.

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 ('settle a completed trade and release escrow funds') and the resource, with specific technical details. However, it does not explicitly differentiate from sibling tools like thread.expire_escrow or thread.file_dispute, relying on context.

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 after a trade is completed ('Buyer-side: settle a completed trade'), but provides no explicit when-not or alternative tool guidance. With many siblings, this is adequate but not 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 are provided, so the description carries full burden. It discloses that Bridge builds and signs the document internally, but lacks details on side effects, authentication, rate limits, or error conditions. The return values are listed, which adds some 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?

Three sentences, each with a clear role: purpose, usage hint, and return values. No wasted words; front-loaded with purpose.

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

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

Given 5 parameters and no output schema, the description covers the purpose, the key workflow (poll for acceptance_id_hex), and the return structure. It could be more detailed on prerequisites or error handling, but is generally sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds a usage hint for acceptance_id_hex, but does not significantly expand on schema descriptions for other parameters like secret_key_hex or milestone_index. It does not degrade but also does not elevate.

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 that Bridge builds and signs the COSE_Sign1 Delivery document internally. It distinguishes from siblings like thread.poll_delivery by describing the submission action and providing a follow-up hint.

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 tells when to use the tool (after buyer accepts, seller submits work) and how to find the required parameter acceptance_id_hex using thread.poll_delivery. It implies the flow but does not explicitly list prerequisites or when not to use it.

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

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

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?

Discloses the effect (credits balance, zeros stake), idempotency, and return fields. With no annotations, this provides solid behavioral insight, though it could mention failure modes or permissions.

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?

Four sentences, front-loaded with purpose, followed by mechanism, usage condition, and return. No wasted words; 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?

Covers main action, prerequisite, idempotency, and return structure. Missing details like what 'PG status retired' means or behavior if called early, but adequate for a simple tool.

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

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

Schema coverage is 100%, and the description adds no extra meaning beyond the schema's own description ('32-byte Ed25519 seed (hex)'). Baseline score 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?

Clearly states it releases stake_locked_micro on chain and mentions prerequisite thread.wind_down, distinguishing it from the sibling tool thread.wind_down. However, it could explicitly contrast with similar release 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?

Explicitly says 'Should be called after thread.wind_down has marked PG status retired,' giving clear context. Does not include exclusions or alternative tools but is sufficient for this tool.

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