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 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 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 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?

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.