KHOTEM — Cryptographic Witness

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

With no annotations, the description carries the full burden and does disclose cost, payment ordering, and exact-match behavior. However, it does not state whether the operation mutates the ledger, what happens when no record matches, or what the response contains. This is useful but incomplete 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 compact, front-loads the paid nature, and communicates the core behavior and parameters in three short clauses. Every sentence provides distinct, necessary 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?

For a two-parameter tool with no output schema, this description covers the essential calling requirements: cost, ref formats, exact-match semantics, and payment ordering. It lacks details about response shape and sibling-tool differentiation, but the tool is simple enough that an agent can likely invoke it correctly with this information.

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%, so the description must add meaning, and it does: ref is explained as a txHash, sha256, or 16-hex stamp, and payment_tx is tied to the pay-first instruction. It still leaves payment_tx format and exact source unspecified, but it meaningfully compensates for the bare string types.

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 clear action: produce a certificate of existence by exact-matching a ledger record. It also specifies the acceptable forms of ref (txHash, sha256, 16-hex stamp). It does not explicitly distinguish itself from siblings like khotem_seal or khotem_receipt_verify, 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 description gives explicit operational guidance: pay first, then pass payment_tx, and use exact-match semantics on ref. It does not describe when not to use the tool or name alternatives, but the core precondition and matching behavior are 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 disclosure burden. It usefully discloses that the catalog is FREE and explains what it contains, but it does not describe the output shape, size, or whether this is a read-only lookup. Acceptable for a zero-parameter list tool, but not fully transparent.

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 front-loaded, high-signal sentence: FREE, full catalog, paid services, prices in USD, and payment methods. No filler or 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 no-input catalog tool, the description adequately conveys what the agent will get: services, prices, and payment instructions. It slightly under-specifies the response format or length, but the low complexity and absent parameters make this 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?

The input schema has no parameters, so there is nothing to explain beyond the schema. The zero-parameter baseline of 4 applies, and the description avoids inventing unnecessary 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?

States a specific deliverable: a full catalog of paid KHOTEM services with USD prices and payment methods (x402 direct, USDC on Base). This is immediately distinguishable from sibling action tools like khotem_attest or khotem_seal.

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

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

The usage context is clear: call this tool when you need the full list of paid KHOTEM services, their prices, or how to pay. It does not explicitly name alternatives or exclusions, but the catalog role versus verification/action siblings is evident.

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 burden of behavioral disclosure. It reveals that this is a paid operation costing $0.10, that it returns a course id, and that it changes payment economics for subsequent calls. However, it omits information about failure modes, refunds, idempotency, or what happens if payment_tx is invalid.

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 compact and packs cost, workflow, return value, and next steps into two sentences. The wording is telegraphic and could be smoother, but every sentence carries necessary information and the key behavioral constraint is front-loaded.

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

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

The core flow is covered: payment, course id, header usage, and zero per-call cost. However, there is no output schema, no details on the HTTP routes to call, no error handling context, and no clarity on whether payment_tx is effectively required despite being unmarked as required.

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

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

Schema coverage is 0%, so the description must compensate. It adds meaning by saying 'Pay first, then pass payment_tx,' which explains the temporal dependency and the purpose of the parameter. It does not specify format or where payment_tx comes from, but it provides enough semantic context for the single parameter.

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

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

The description identifies a specific action: one payment purchases a course that unlocks five procedures (spa/med/attest/trust-score/seal) and returns a course id. It is not a tautology and clearly distinguishes the course from individual procedure tools, though it does not explicitly name any sibling alternative.

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 a clear workflow: pay first, pass payment_tx, obtain a course id, then use it in an X-COURSE header for subsequent calls at zero per-call cost. It does not explicitly state when not to use this tool or name alternatives, but the intended 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 provided, the description carries the full burden. It discloses cost ($0.10), determinism, technical mesh details (marching-columns, self-made font, LCG grain), and output formats. It also clarifies the payment flow. However, it omits the payment destination (e.g., where to send USDC) and what happens after payment—whether output is returned as files or URLs. These gaps prevent a perfect score.

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 sentence that front-loads the most critical information (cost and purpose) and packs in all necessary details: determinism, output formats, mesh technique, font, and payment instructions. No wasted words. The structure is effective for quick parsing.

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 of a paid 3D generation tool with payment, parameters, and output, the description is incomplete. It fails to specify where to send payment (the USDC address or payTo address mentioned in the schema), how the output is delivered (download link, direct binary?), and what happens if payment fails. The schema mentions 'payTo' in the payment_tx description, but the tool description doesn't explain how to obtain that address. These gaps hinder an agent from executing the tool 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%, so the schema already documents all three parameters. The description adds context about payment_tx being required ('Pay first, then pass payment_tx') and seed being optional, but this contradicts the schema's required list (only 'word' is required). This creates ambiguity about whether payment_tx is mandatory. The description adds value by explaining the payment flow, but the inconsistency with the schema lowers the score.

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: 'FORGE: deterministic 3D relief medallion of your word' with specific output formats (GLB+OBJ). This distinguishes it from siblings like khotem_seal or khotem_med, which likely have different purposes. The verb 'forge' is specific and the resource is a medallion, 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 provides explicit usage steps: 'Pay first, then pass payment_tx + word (+seed).' This tells the agent the required sequence and prerequisites. It doesn't explicitly mention when not to use this tool or alternatives, but the unique paid 3D medallion generation clearly separates it from other khotem_* tools. The payment-first instruction is a strong usage guideline.

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

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

No annotations are provided, so the description carries the burden. It discloses several behaviors: payment required, code size limit (<=2KB), 1:1 restoration with sha256 equality, and the state fold contents. However, it doesn't disclose what happens on failure, whether the code is stored, or what 'KUDO-wrapped' means operationally. It adds meaningful behavioral context but leaves 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 compact and front-loaded with the key constraint (PAID $0.01) and the core action. It packs a lot of information into two sentences without redundancy. Slightly dense with jargon (KUDO-wrapped, state fold) but each phrase earns its place.

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

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

For a 2-param tool with no output schema and no annotations, the description covers the main flow, payment requirement, and expected result. However, it lacks details on error cases, payment_tx format, and what the state fold looks like. Given the tool's complexity (payment + code processing), it's adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions payment_tx and code by name and explains their roles ('pass payment_tx + code'), but it doesn't clarify the format of payment_tx (e.g., hex, JSON, transaction hash) or the exact expected code encoding. The description adds some meaning but leaves critical format details undocumented.

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: send code through a KUDO-gate, get it wrapped/restored, and receive a state fold. It distinguishes from siblings by naming 'depth 0' and the gate concept, though it doesn't explicitly name a sibling alternative. The verb 'send' and resource 'code' are clear.

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

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

The description gives explicit usage context: pay first, then pass payment_tx + code. It implies this is the shallow gate (depth 0) versus khotem_gate_deep, which is a clear alternative signal. It doesn't explicitly say when not to use it, but the payment-first instruction and depth mention provide adequate guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose cost, a payment prerequisite, jail/sandbox execution, and the .kudo-only restriction. However, the meaning of 'forge fold', depth-dependent behavior, and any side effects or return behavior are not 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 compact and front-loads the most decision-relevant fact, the cost. Each clause adds information about payment, execution scope, or how to call the tool, though the cryptic 'forge fold' phrase could be clarified without much added length.

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

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

For a paid execution tool with no output schema, no safety annotations, and many siblings, the description omits return values, failure modes, and what each depth level changes. An agent might attempt a call but cannot confidently predict or handle the result.

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 three parameters are at least referenced, and the description adds meaning beyond the bare schema: depth is range 1-3, payment_tx is proof of payment, and code can be wrapped from any language but only .kudo executes. With 0% schema description coverage, this partial compensation is useful though still vague on exact formats and depth 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 names 'KUDO-GATE depth 1-3' and lists 'static read / .kudo execution in jail / forge fold', but these are unexplained jargon rather than a clear verb+resource statement. An agent can infer that .kudo code may be executed, but the overall function, especially 'forge fold', remains ambiguous.

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 provides a sequencing rule ('Pay first, then pass payment_tx + code (+depth)') and a restriction ('only .kudo executes'), but it never states when to use this tool over khotem_gate or the other siblings. No alternatives, exclusion criteria, or context-for-use 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 full behavioral burden. It does state 'FREE' and describes the tool as a 'step-by-step guide,' which signals an informational, non-transactional operation. However, it does not explicitly disclose that the tool performs no state changes, returns documentation text, or requires any authentication, leaving some behavioral ambiguity for an agent.

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

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

The description is a single, compact sentence that front-loads the key 'FREE' signal and immediately states the tool's purpose. Every element adds value: the step-by-step nature, the payment topic, the x402 v2 version, and the relevant header examples. There is no redundant or filler text.

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 guide tool with no output schema, the description covers the essential context: what the guide teaches, which protocol version, and the exact header formats. It could marginally improve by noting the return format or that the guide is plain documentation, but the current content is sufficiently complete for an agent to understand what this tool offers.

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 the baseline for this dimension is 4. There is no schema information to elaborate on, and the description correctly focuses on the guide's content rather than inventing parameter details. Nothing extra 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 clearly identifies the tool as a step-by-step guide for paying and calling KHOTEM, naming the specific protocol (x402 v2) and relevant headers (PAYMENT-SIGNATURE / X-PAYMENT: txHash). This is a distinct meta-tool compared to sibling operation tools like khotem_seal or khotem_attest, though it uses a noun ('guide') rather than a direct verb. It is specific enough to avoid confusion with the other KHOTEM 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 implies the tool should be used when an agent needs instructions on how to pay and call KHOTEM, but it does not explicitly state when to use it versus the sibling tools. It names the covered topics but offers no direct guidance about prerequisites or the order of operations relative to khotem_seal, khotem_attest, or khotem_status. Usage context is inferable 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?

With no annotations, the description supplies some behavioral context: it is FREE, returns only solutions/advice (route, price, why, ETA), and is fast (<1 min). It does not state whether the tool mutates anything, requires auth, or has limits/fallbacks, so it does not fully carry the burden.

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 compact sentence, front-loaded with the cost signal (FREE), then the core behavior and output elements. Every clause earns its place; 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 intake tool with no output schema, the description names the input format and the main return elements (route, price, why, ETA). It falls just short of complete because it doesn't state boundaries (e.g., that it doesn't execute the route/booking) or how ambiguous requests are handled.

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 has one required string `want` with 0% description coverage. The description compensates by specifying that `want` is free text representing the user's need, which is the key semantic info an agent needs; there are no enums or nested constraints to document.

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

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

States the tool is a free-form intake/front door that turns a natural-language want into concrete solutions with route/price/why/ETA. It clearly distinguishes its role from the specialized sibling tools by calling itself the 'front door,' though it does not name an alternative explicitly.

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

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

'Concierge front door' and 'say what you need in free text' establish when to use it: as a starting point for unspecified or unstructured requests. It does not mention explicit exclusions or name which specialized sibling to prefer for a given need, so it stops short of a 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?

No annotations are provided, so the description carries full burden. It discloses a critical behavioral trait: the tool requires payment and will likely not work without a valid payment_tx. However, it does not disclose what happens if payment fails, the exact response format, or whether the tool has side effects (e.g., recording the payment). This is a significant gap.

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

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

The description is one compact sentence that front-loads the payment requirement and summarizes the tool's function and output. Every phrase builds on the previous one, and there is no wasted text. It is efficient and easy 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?

The tool has only two parameters and no output schema, which is relatively simple. The description covers the essentials: what it does, the payment requirement, and the input needed. However, it does not describe the diagnosis categories in detail (though it lists them) or the exact structure of the prescription. This is adequate but could be improved with more clarity on outputs.

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 50%: the 'wallet' parameter is described as '0x address', but 'payment_tx' has no description. The description clarifies that payment_tx is the payment transaction, which adds some meaning, but it does not specify the format or how it is used. With coverage at 50%, the description partially compensates but not fully.

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: it performs diagnostics for an agent wallet on Base, checking on-chain vitals and KHOTEM ledger history, and provides a diagnosis and prescription. This is clear and distinguishes it from sibling tools like khotem_status or khotem_gate, though it doesn't explicitly name them.

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

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

The description clearly states that payment is required first, and the agent must pass payment_tx after paying. It also implies the tool is used for diagnostic purposes, but it does not explicitly mention when not to use it or alternative tools, though the context of the sibling names suggests alternatives. This is adequate for a paid tool.

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 disclosure burden. It discloses that the operation is free, echoes the input, and adds a sha256 stamp and server time, leaving little ambiguity about side effects or cost. It does not specify edge behavior for empty text, but that is minor for a ping 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?

One compact sentence with the value proposition front-loaded ('FREE. Zero-threshold handshake') and the exact behavior stated immediately. No filler or 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 one-parameter ping tool, the description covers what to send, what to expect back, and the cost/access context. It does not explicitly address the fact that the parameter is optional per the schema, but that 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?

The schema already fully describes the single text parameter, including the <=200 chars constraint. The description restates the concept ('send any text') but adds no parameter-level detail beyond the schema, so a 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 identifies a handshake/echo operation: send any text and get it echoed back with a sha256 stamp and server time. This is distinguishable from siblings like khotem_seal or khotem_receipt by its zero-threshold connectivity-test purpose.

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

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

The description explicitly frames the tool as a free, zero-threshold way to prove the whole path works before paying, which tells the agent when to use it. It does not explicitly name alternatives or exclusions, but the use case 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 provided, the description carries the burden of behavioral disclosure. It meaningfully reveals cost ($0.01), the signing scheme (Ed25519), portability, and the payment-first requirement. It does not mention return format or failure behavior, but the key behavioral traits are disclosed.

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 compact and front-loaded, with every sentence adding relevant information: cost, product, verification path, and usage sequence. There is no filler or repetition.

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 two-parameter tool with no output schema, the description covers purpose, cost, verification, and invocation order. It could be more explicit about the exact output format and the expected values for ref and payment_tx, but it gives enough context for an agent to proceed.

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%, so the description must compensate. It hints that 'ref' is a ledger ref and that 'payment_tx' should be passed after paying, but it does not explain their formats, relationships, or why payment_tx is optional in the schema. This is partial compensation, not complete.

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 the tool produces a portable Ed25519-signed proof-of-delivery receipt for a ledger ref, which is specific and distinguishes it from the verify sibling. It lacks an explicit verb like 'create' or 'get', but the context and sibling names make the intended action clear.

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

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

The description gives clear operational guidance: pay first, then pass payment_tx, and verify free via khotem_receipt_verify. However, it does not explain when to use khotem_receipt instead of related tools like khotem_attest or khotem_seal, so some alternative-selection context is missing.

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?

There are no annotations, so the description must carry the full burden of behavioral disclosure. It mentions 'FREE' and lists the verification checks, but it does not state whether the operation is read-only, what the success/failure response looks like, whether it performs any writes, or if authentication is required.

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 exceptionally concise: two short sentences with no filler. 'FREE.' adds a practical cost signal, and the main sentence front-loads the tool's core purpose and verification scope. 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?

For a tool with two required nested-object parameters, no output schema, and no annotations, this description leaves significant gaps. An agent can tell what the tool does, but not how to construct valid inputs, what the response format is, or how verification results are reported.

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%, and both parameters are opaque nested objects. The description names verification-related concepts like signature, payload hash, ledger anchor, and issuer key, but it does not explain how these map to the 'receipt' and 'proof' parameters or what structure those objects should have.

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 a specific verb and resource: 'Verify a KHOTEM Ed25519 receipt'. It further clarifies what verification covers—signature, payload hash, ledger anchor, issuer key—which goes well beyond the tool name and distinguishes it from receipt creation or attestation 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 implies the tool should be used when a KHOTEM receipt and proof need verification, but it does not explicitly state when to use it versus siblings like khotem_receipt or khotem_seal. No exclusions, prerequisites, or alternative tool references are 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?

With no annotations, the description carries the behavioral burden. It discloses the $0.02 payment requirement-elow crucial side effect—and states the return value. It does not mention failure modes (e.g., invalid payment_tx, already joined) or whether joining is idempotent, but the core financial behavior is explicit.

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 compact and front-loaded with the critical payment cost and room identity. The key behavioral instruction ('Pay first, then pass payment_tx') appears at the end, and the marketing phrasing ('fat USDC') adds noise but does not obscure the essential 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?

For a single-parameter tool with no output schema, the description supplies the required input, the action (join room), the price, the sequence, and the return value (room id + write key). It is sufficiently complete, though it omits failure/error behavior and payment 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?

The input schema provides only a type for payment_tx with no description (0% coverage). The description adds that it is the payment transaction and must be provided after payingasippling meaningful context beyond the raw schema but no format, source, or validation 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 uses a clear verb+resource pair: 'Join the INSIDE room (VIP)'. It states the benefit (daily intel digests, market radar) and the outcome (room id + write key). It does not explicitly distinguish itself from sibling tools, but the action and deliverable are 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 gives an explicit sequence: 'Pay first, then pass payment_tx.' It communicates the prerequisite for using the tool. However, it does not describe when to choose this tool over alternatives or what context makes it appropriate beyond wanting membership.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool is paid ($0.05), that content is 'hashed and forgotten' (privacy-preserving), that a timestamped ledger record is produced, and that payment_tx must be passed after paying. It does not cover failure modes or confirmation behavior, but it provides substantial 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 short, purposeful sentences with no filler. The description front-loads the critical paid nature, states the core function, then gives the precise input/payment instruction. Minor structural inefficiency: 'PAID $0.05' could be a note after the function, but it is still 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?

The description is solid for a paid tool with no annotations and no output schema: it covers payment, input alternatives, and the ledger effect. However, it does not explain what the caller receives in response, how to obtain or validate the payTo address, or what happens on invalid/insufficient payment. These are meaningful gaps for 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 only 33%, yet the description compensates by explaining that content and hash are alternative inputs and that content is discarded after hashing. It also clarifies the payment_tx requirement, while the schema already describes payment_tx as a Base USDC transfer txHash. It does not define hash format or content constraints, but the core param relationships are clear.

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 outcome: 'Witnessed cryptographic seal: sha256 + timestamp + ledger record.' This clearly identifies the tool as a sealing/witnessing operation and differentiates it from simple pings or queries, though it does not explicitly contrast with siblings like khotem_attest or khotem_receipt.

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 operational guidance: 'Provide content (hashed and forgotten) or hash. Pay first, then pass payment_tx.' This explains how to invoke the tool and the required payment flow, but it does not state when to choose this tool over its siblings 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?

With no annotations, the description carries the behavioral disclosure load. It reveals the tool is paid ($0.02), deterministic, has an input size limit (≤256KB), and lists output features (essence, repeated patterns, compression ratio, sha256). It also states the payment flow (pay first, then pass payment_tx). This is substantial, though it does not mention side effects, error handling, or what happens if the payment fails.

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 highly compact, using a concise arrow notation and front-loading the paid status and purpose. Every sentence adds value: cost, operation, parameters, and payment flow. There is zero fluff and it fits a single breath, making it easy for an agent to parse quickly.

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 the complexity, the description covers the core operation, input limit, output features, and payment requirement. It is mostly complete for an agent to invoke correctly. However, the 'max_essence' parameter is left ambiguous, and there is no explicit output schema (though the description lists output elements). For a paid tool with no annotations, this is a solid attempt but leaves 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?

Schema description coverage is 0%, so the description must explain parameters. It clarifies 'text' as noisy context/logs and 'payment_tx' as a payment transaction token (implied via 'then pass payment_tx + text'). However, it does not explain 'max_essence' at all. This leaves one of three parameters undocumented, so the description only partially compensates for the missing schema descriptions.

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

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

The description clearly states the operation: it takes noisy context/logs (text) and produces a distilled essence with specific characteristics (rarity×diversity, deterministic, etc.). The verb-resource mapping is specific and the purpose is understandable. However, it does not explicitly differentiate this tool from the many khotem_* siblings, relying on the abbreviation 'SPA' which may be ambiguous.

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

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

The description implies a use case ('Agent context SPA' and 'dump noisy context/logs') and a prerequisite ('Pay first'), but it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. It gives context for usage but no direct comparison with sibling tools, so an agent must infer when this is appropriate.

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 is the only behavioral source. It usefully discloses that it's free, gas is paid by the facilitator, and the output is the user's exact state plus the single next step. It doesn't state side effects, but the wording implies a guided read-style interaction.

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 punchy sentences with no waste. 'FREE' and 'No gas needed' are front-loaded, and the value proposition is 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?

For a simple zero-required-param onboarding tool, the description covers cost, gas behavior, input, and output. It doesn't describe error cases or exact response schema, but the context signals suggest minimal complexity.

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

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

Schema coverage is 100% with one optional 'address' parameter. The description reinforces that the wallet can be omitted ('or none') and indicates it's used for state lookup, adding slight semantic context 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 the resource (guided onboarding) and the action (reports wallet state and next step). It would be clearer with explicit differentiation from sibling tools like khotem_guide, but the phrasing is sufficiently specific.

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

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

It conveys the intended context: onboarding, starting with optional wallet. However, it gives no explicit when-to-use versus khotem_guide or other siblings, 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?

There are no annotations, so the description carries the full burden of explaining behavior. It discloses that the tool reports version, mode, and liveness, which implies a safe read-only status operation, but it does not clarify what 'mode' means or how liveness is determined.

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 compact and front-loaded, using 'KHOTEM service status: version, mode, liveness' efficiently. The leading 'FREE.' is unexplained and arguably non-essential, preventing a perfect score.

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

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

For a no-input status operation, the description provides enough information about what the tool returns, which matters given the lack of an output schema. It would be more complete with details on response format or the meaning of mode/liveness.

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 accepts zero parameters and the schema documents this completely, so no parameter explanations are needed. The baseline for zero-parameter tools 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 identifies a specific resource (KHOTEM service status) and lists the returned information (version, mode, liveness), making the tool's purpose clear despite lacking an explicit verb. It does not explicitly distinguish itself from khotem_ping, which may also report liveness.

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

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

No guidance is provided on when to use this tool versus khotem_ping or other siblings. The phrase 'service status' implies a health-check use, but the description gives no explicit context, prerequisites, or alternatives.

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

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

With no annotations, the description discloses the paid nature ($0.25), payment-first ordering, and output range. It also names data sources and risk flags. It does not cover failure modes or output structure, but core behavioral context is 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?

Two tight sentences; the most important fact (PAID $0.25) is front-loaded and every clause adds information. 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?

Covers cost, order, and result range, but leaves ambiguity around payment_tx (optional in schema yet described as required, format unclear) and does not describe the result structure beyond the numeric score. For a paid tool with no output schema, a bit more detail would help.

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?

Target is described in the schema as '0x address'; the description adds that it is a wallet/agent. Payment_tx is mentioned but not described beyond being the payment transaction to pass after paying. With 50% schema coverage, the description partially compensates but leaves the format of payment_tx unspecified.

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 output (trust score 0-100) and resource (any Base wallet/agent), with data sources (witness ledger, risk flags, seal). It does not use an explicit verb like 'returns' and doesn't contrast with siblings, but the intent is 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 a clear operational sequence ('Pay first, then pass payment_tx + target') but no guidance on when to prefer this over sibling tools or exclusions. Usage context is implied by the paid trust-score purpose rather than explicit.

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