DAEMON — on-chain generative art (8004 NONCE + KOINE)

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

With no annotations, the description carries the burden of behavioral disclosure. It states what data is returned, including the useful distinction of 'current owner,' but does not mention whether the operation is read-only, how errors are handled, or any other behavioral caveats. This is adequate but not thorough.

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 one efficient sentence with the key point front-loaded: traits plus current owner. The colon-separated field list adds concrete detail without verbosity. No redundant or filler wording is 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?

For a simple one-parameter lookup with no output schema, the description enumerates the return fields, which is the critical missing information. Minor gaps such as the exact representation of the owner or behavior for nonexistent ids remain, but they are not severe for this tool's complexity.

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

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

Schema description coverage is 100%: the sole 'id' parameter is already documented as the token id with a range hint for the genesis. The description adds only that the token is a 'KOINE token,' which is marginal and does not meaningfully extend the schema's 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?

The description clearly identifies the resource ('one KOINE token') and the data returned: traits and current owner, with specific fields listed. It does not use a verb like 'retrieve' and does not explicitly differentiate from siblings such as koine_provenance, so it falls short of a 5.

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

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

The scope 'one KOINE token' and the phrase 'current owner' imply when the tool is appropriate: for a single token's current state rather than lists or provenance. However, it does not explicitly state when to use it over alternatives or when not to use it, so usage guidance is only implied.

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

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

With no annotations provided, the description carries the full burden. It implies a read-only overview by listing informational fields and avoids any hint of mutation, but it does not explicitly state that there are no side effects or describe any access constraints. The behavior is adequately transparent for a zero-parameter info tool, though not deeply detailed.

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 the core overview scope and contents front-loaded in the first clause. Every phrase earns its place: the second sentence adds necessary context about the collection's on-chain nature and author 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?

For a simple, zero-parameter tool with no output schema, the description is complete: it names the resource and lists the expected returned fields. The background about Ethereum L1 and DAEMON gives helpful context, and no critical invocation detail is missing.

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

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

The input schema has zero parameters, so the baseline is 4. The description adds no parameter-level detail because none is needed, and it appropriately focuses on what the returned overview contains.

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

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

The description uses a specific resource scope, 'KOINE collection overview,' and enumerates the exact contents: name, total supply, DAEMON, contract address, chain, and links. This clearly distinguishes it from sibling tools like koine_get_piece or nonce_info, which target different resources or granularity.

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

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

The phrase 'KOINE collection overview' signals that this tool is for high-level collection information, while the sibling set implies that piece-level queries belong elsewhere. It does not explicitly mention when not to use it, but the scope is clear enough for an agent to select it for overview-style requests.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'List every' and the enumerated fields indicate a read-only, unfiltered enumeration, but it does not disclose pagination, ordering, output size, or any operational constraints.

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

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

One sentence with no wasted words. The action, scope, and output fields are all front-loaded and compact.

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

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

For a zero-parameter list tool with no output schema, the description is largely sufficient: it names the resource, the fields returned, and the intended purpose. The main gaps are the lack of sibling differentiation and any limitations on result size.

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 zero parameters, so parameter documentation is moot. The description adds no parameter detail, but none is needed; the baseline of 4 for zero-parameter tools 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?

States a specific verb and resource: 'List every KOINE piece' with the included fields. It is clear what the tool returns, but it does not explicitly distinguish itself from the sibling 'koine_listings', so it falls short of full differentiation.

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

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

The phrase 'for discovery and composition' gives an implied use case, but there is no explicit guidance on when to choose this tool over siblings like koine_get_piece or koine_listings, nor any stated exclusions.

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

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

With no annotations, the description carries the full burden, and it delivers: it discloses that results are sorted cheapest first, that collection/contract/OpenSea link are always returned, that live listings appear only when an OpenSea API key is configured, and that fulfillment requires a funded Seaport-capable wallet.

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 essential purpose and sort order, then return behavior, then action implications. No filler or repeated information.

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

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

For a zero-parameter tool with no output schema, the description covers purpose, sort order, return fields, conditional output, and next steps. It is slightly compact on whether the result is a list of items, but it remains sufficient 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?

The input schema has zero parameters, so there is nothing to document; the baseline is 4. The description adds relevant context about the server-side OpenSea key that changes output, which is more useful than 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 states a specific action and resource: list KOINE pieces currently for sale, sorted cheapest first, for collection. The phrase 'currently for sale' and the mention of Seaport orders separate it from siblings like koine_get_piece or koine_list_genesis.

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 makes it clear this tool is for collecting/buying KOINE pieces and explains the on-chain fulfillment path. It does not explicitly name alternative tools for other scenarios, but the context is clear enough for an agent to know when to call 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 the full burden. It does disclose the data source and output scope, and clearly implies a read-only query. However, it does not mention error behavior, traversal limits, ordering, or the exact response 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?

One tightly worded sentence that front-loads the purpose, then gives concrete output categories. Every part of the sentence adds useful information with no filler.

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

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

Despite having no output schema, the description conveys the key return categories: parents, full ancestry, and downstream adoption. It is adequate for a simple one-parameter lookup, though edge-case behavior and output details are not specified.

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

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

The schema fully documents the single `id` parameter as a token id, so schema coverage is 100%. The description adds no additional parameter semantics, but none are necessary at this 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 identifies the operation: retrieving lineage/provenance of a KOINE piece from the on-chain derivation graph. It enumerates the concrete outputs—parents, full ancestry, and downstream adoption—which distinguishes it from siblings like koine_get_piece or koine_verify.

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

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

Usage is implied: an agent can infer this tool is for provenance/lineage questions. However, there is no explicit statement of when to prefer it over alternatives or when not to use it, so the routing guidance remains implicit.

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 transparency burden. It usefully explains that the call is on-chain and defines canonical_ok precisely, but it never states that the call is read-only/non-mutating and gives no error or invalid-id behavior.

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

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

The core behavior and return shape are front-loaded in a compact sentence. 'THE KEYSTONE' and the final 'One call...' are slightly redundant, but the definition is still 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?

For a one-parameter tool with no output schema, the description supplies all key output fields and explains the crucial canonical_ok meaning. It omits failure modes and any relationship to sibling tools, but otherwise an agent can call it correctly.

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

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

Schema coverage is 100%; the 'id' parameter is already described as 'token id to verify'. The description only echoes verify(id) and adds no extra semantic detail, 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 names a specific verb-resource pair ('Calls the contract's on-chain verify(id)') and specifies the exact trust-related return fields. It does not explicitly distinguish itself from koine_provenance or nonce_verify, so it misses the top tier.

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?

Phrases like 'THE KEYSTONE' and 'One call, a trustable answer' imply this is the primary tool for obtaining on-chain verification, but no explicit when-to-use/when-not-to-use guidance or named alternatives are given.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the data is live, read from the chain, and limited to raw counts with no interpretation. It also clarifies that band supplies are uncapped and emergent, which prevents a common misinterpretation. It does not detail output shape or pagination, but the parameter schema covers the sampling limit and cost rationale.

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 concise sentences, each earning its place: the tool's core function, an important semantic caveat about band supplies, and a clear statement of what the response contains. The most important information is front-loaded and there is no filler.

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

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

For a single-parameter, read-only census tool, the description is reasonably complete even without an output schema. It tells the agent what the tool returns (raw counts across difficulty bands) and what it does not do (interpretation). Slightly more detail about the exact response shape would strengthen completeness, but the description covers the essential usage context.

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

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

Schema coverage is 100% for the single `limit` parameter, including default, min/max, and rationale about eth_call costs and RPC rate limits. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description clearly identifies the tool's function: reporting the live distribution of minted 8004 NONCE pieces across difficulty bands. It distinguishes itself from sibling tools by emphasizing that it returns aggregate raw counts, not piece-level data or interpretation, and by noting this is a chain-read census rather than a mining/minting operation.

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 when to use the tool: when you need the current difficulty-band distribution and raw counts, not analysis. However, it does not explicitly name alternatives or state exclusions, such as 'use nonce_get_piece for individual pieces' or 'use nonce_spec for band definitions.' The guidance is left largely implicit.

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 present, so the description carries the behavioral burden. It does disclose that every value is read live from the chain, which is useful and signals a real-time read rather than cached data. However, it does not mention failure behavior, finality, auth, or side effects; the absence of annotations leaves those 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?

Two sentences, no filler; the scope is front-loaded and each listed field earns its place. Very efficient for an AI agent to parse.

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 one simple parameter and no output schema, the description does enough by listing the return fields (seed, difficulty, band, rarity, owner, links) and stating the live-chain read. It does not discuss errors or edge cases (e.g., nonexistent token id), but for a get-by-id read the core context is 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?

Schema coverage is 100%, and the id property is already described as a 0-based token id with DAEMON genesis range. The description adds no parameter-level meaning; it focuses on response fields. Baseline 3 applies because the schema carries the documentation burden.

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

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

The description opens with 'Full detail on one 8004 NONCE token' and enumerates the exact fields returned, so an agent immediately knows the verb (get one token) and resource. It is distinguishable from a census/list tool by 'one token', though it does not explicitly name any sibling alternative, so not a 5.

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

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

No when-to-use or when-not-to-use guidance is given, and no sibling alternatives are mentioned even though nonce_census and nonce_info exist. The only usage signal is the word 'one', which weakly implies this is for single-token lookups; there are no exclusions or routing conditions.

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

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

With no annotations provided, the description carries the full burden and handles it well: it explicitly says the information is live, is on Ethereum mainnet, and that minting has a mining prerequisite. This clearly implies a read-only status query with no side effects, though it stops short of describing response format or canonical links behavior.

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

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

Two sentences deliver the essential information without filler. The first sentence front-loads the live-state purpose and enumerates the returned fields; the second provides helpful collection context. Every sentence earns its place.

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

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

For a zero-parameter, no-output-schema status tool, this description is complete: it states the network, the data fields returned, the public-mint status, and the proof-of-work context. No additional information is necessary for an agent to decide to call it and interpret its purpose 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?

The tool takes zero parameters, so the input schema already fully defines the calling contract. The description adds value by explaining what the returned live state covers, which is the only meaningful semantic content needed for a parameterless tool.

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

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

The description names a precise resource (the 8004 NONCE collection) and a specific action: reporting live state. It enumerates exact data points returned (minted count, current mint price, public minting open status, supply remaining, canonical links), making the tool's purpose unmistakable and distinguishable from sibling tools that focus on pieces, verification, or mining.

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

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

The phrase 'live state' implies this is the tool to call for current dynamic status rather than static collection specs or individual piece lookups. However, there is no explicit guidance about when to choose this over siblings like nonce_census or nonce_spec, and no exclusion criteria.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the operation grinds keccak256, is deadline-bounded, returns the nonce/work hash/difficulty/band, and that the nonce is bound to (chainId, contract, minter). It also notes that if the target is not reached within the time budget, the best valid nonce found is still returned. This is rich, honest behavioral detail.

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 core facts are front-loaded and the structure moves from purpose to binding warning to return values to deadline guidance. The only waste is the opening 'DO THE WORK.', which is stylistic but not informative. Every other 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 no output schema, the description compensates by listing exactly what is returned: nonce, work hash, difficulty in leading-zero bits, and band. It also covers timeout behavior and the high-difficulty alternative, and the sibling context shows where this fits before nonce_mint_packet. Nothing critical is missing 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 description coverage is 100%, so the baseline is 3 because the schema already documents minter, maxSeconds, and targetBits well. The description adds conceptual context about nonce binding and why mining for the correct address matters, but it does not add new parameter syntax or format details beyond the schema. That is adequate but not exceptional.

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

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

The description opens with a specific verb and resource: 'Grinds keccak256 to find a proof-of-work nonce valid for a specific minter address.' It clearly states the purpose and distinguishes this tool from siblings by calling it 'the only way to become eligible to mint an 8004 NONCE piece.' This is precise, not a tautology.

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 when to use the tool ('This is the only way to become eligible to mint') and when not to: 'for difficulty above ~20 bits, run the local miner script instead of waiting on a server.' It also warns that the nonce is bound to the minter address, so the agent must mine for the address that will send the transaction. This is clear decision guidance.

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

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

No annotations are provided, so the description must carry the transparency burden. It does: it guarantees never touching private keys, re-derives and re-checks the proof before emitting, reads live price(), and fails locally on bad nonces rather than burning gas. It could be more explicit that broadcasting is left to the user, but 'ready-to-broadcast' and 'copy-paste commands' strongly imply it.

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 dense sentences with no filler. The first front-loads purpose and output, the second adds a key security guarantee, and the third explains validation and failure behavior. Every sentence earns its place.

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

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

With no output schema and no annotations, the description covers the return shape ({to, data, value} plus commands), the prerequisite input (mined nonce), and critical failure behavior. The only minor gap is that broadcast semantics are implied rather than explicitly stated, though 'copy-paste commands' makes the intended flow reasonably clear.

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

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

Schema coverage is 100%, so the schema already documents nonce, minter, and slippageBps thoroughly. The description adds only mild contextual framing, such as the nonce coming from mining and slippage protecting against price movement, which mostly mirrors the schema. This is the baseline-3 case where the schema does the heavy lifting.

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

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

The description names a specific verb and resource: it 'builds a ready-to-broadcast mint transaction from a mined nonce' and enumerates the output ({to, data, value}) plus wallet commands. This clearly distinguishes it from siblings like nonce_mine and nonce_verify, which have different roles in the nonce lifecycle.

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 conveys the pipeline position: use it after a nonce is mined and before broadcasting via MetaMask Agent Wallet or Bankr. However, it never explicitly names alternatives or states when not to use the tool, so the usage guidance is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden and does well: 'Static — needs no network, so it always answers' discloses non-mutating, deterministic, offline behavior. It also discloses coverage of safety rules. It doesn't describe output format, but the 'machine-readable specification' framing implies structured data, which is adequate here.

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 dense sentences with no filler. The first sentence enumerates all key spec components, and the second conveys static availability and the prioritized usage instruction. Every clause earns its place.

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

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

For a zero-parameter, static information tool, the description is complete: it lists all spec categories, states reliability characteristics, and tells the agent to use it first before operations. No output schema exists, but the description's promise of a full machine-readable spec makes the return value expectation clear.

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 zero parameters and the schema is empty, so there are no parameter semantics to clarify. The description appropriately focuses on the specification content rather than pretending parameters exist. Baseline for 0-parameter tools is 4; nothing is missing.

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

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

The description states a specific purpose: providing the complete machine-readable NONCE specification, and enumerates its exact contents (PoW rule, preimage layout, mint calldata, price curve, rarity, selectors, safety rules). This clearly distinguishes it from mining/minting/verifying tools, which operate on the protocol rather than describe 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 gives an explicit usage directive: 'Read this FIRST before mining or minting.' This tells the agent when to consult the spec ahead of operational tools like nonce_mine or nonce_mint_packet. It lacks a when-not-to-use statement or named alternatives, so it doesn't quite reach the full 5.

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 and does well: it discloses the on-chain call, the independent local recomputation using keccak, and the returned triple of chain answer, recomputation, and match status. It does not mention error behavior for nonexistent ids, but the core verification behavior is clearly exposed.

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 functional content is compact and the mechanical steps are front-loaded, but phrases like 'THE KEYSTONE.' and 'Two machines, one truth.' are pure flourish that do not help an agent select or invoke the tool. They add noise without earning their place.

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

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

For a one-parameter tool with no annotations and no output schema, the description is nearly complete: it explains the verification flow and the shape of the return value. The only notable omission is behavior for invalid or nonexistent token ids.

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 fully documents 'id' as the token id to verify (100% coverage). The description confirms id is passed to on-chain verify(id) but adds no new semantic detail beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: it calls on-chain verify(id), recomputes proof-of-work from (minter, nonce), and compares results. It clearly distinguishes itself from simpler verification siblings by emphasizing independent local recomputation and the match comparison.

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

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

The phrase 'machine-decidable trust with no trusted intermediary' implies this is for trustless verification, but the description never explicitly says when to use this tool over alternatives like koine_verify or nonce_mine. There are no exclusions or conditional routing cues.

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