KHOTEM

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

With no annotations, the description carries the full disclosure burden; it does add real context — the $0.50 cost, the pay-before-call requirement, and that output is a sealed report. It does not disclose failure modes (unpaid call, unknown address), whether the report is cached, or anything about rate limits, so gaps remain.

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 dense, front-loaded sentence: price first, then the resource descriptor, then the calling sequence. The em-dash enumeration of report contents is efficient; nothing is padded, though the packed phrasing is slightly list-like.

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?

There is no output schema and no annotations, and the description covers both the return contents and the payment workflow, so an agent has enough to call it correctly. It stops short of describing error handling or what happens if the payment proof is invalid.

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%: 'target' is documented as a 0x address, while 'payment_tx' is bare in the schema. The description compensates by explaining that payment_tx is obtained by paying $0.50 first and then passed alongside target, and that target may be a Base wallet or agent — meaningful semantics the schema lacks.

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 resource — a 'lender-grade credit passport for any Base wallet/agent' — and enumerates the report contents (on-chain vitals, ERC-8004 identity, payment history, risk flags, credit limit, sealed report), which clearly separates it from siblings like khotem_trust_score or khotem_gate. It does not explicitly name or contrast those siblings, so 4 rather than 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?

'Pay first, then pass payment_tx + target' gives a clear precondition and sequencing, which is genuinely useful context. However, it never says when to choose this over alternatives such as khotem_trust_score or khotem_gate, so usage is implied rather than fully guided.

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 and discharges much of it: it discloses the cost ($0.10), the mandatory two-step payment flow, and that matching is exact rather than fuzzy. It omits failure behavior on a non-matching ref and whether payment is per-call or repeatable.

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 terse fragments, with the price front-loaded and the payment ordering immediately after the purpose. Nothing is wasted, though the telegram-style brevity borders on under-explanation.

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 paid tool with no annotations and no output schema, the description covers cost, payment sequencing, accepted ref formats, and the nature of the returned artifact (a certificate of existence). A sentence on mismatch behavior would make it fully complete.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: 'ref' is defined as a txHash | sha256 | 16-hex stamp, and 'payment_tx' is explained as being passed only after payment. This adds real meaning beyond the bare string-typed schema properties.

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

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

States a specific verb+resource combination: issuing a 'Certificate of existence' that exact-matches a ledger record by ref. The scope (exact match, accepted ref formats) is concrete, but it stops short of distinguishing itself from near-siblings like khotem_validate, khotem_receipt_verify, 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?

'Pay first, then pass payment_tx' gives a clear sequencing prerequisite for invocation, which is genuinely useful usage context. However, it offers no guidance on when to choose this over the sibling verification/validation tools, so usage selection 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 full behavioral burden and does disclose useful traits: it is FREE, funds come from 'refund-armed native-USDC custody', the chains (Base/Polygon), and the exact cost model (seller price + $0.05 toll). It omits auth requirements, whether the quote is time-limited or binding, and failure behavior, so it is informative but incomplete for a payment-adjacent 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?

Front-loading 'FREE.' is effective and the return fields are stated compactly. The middle sentence is dense with unexplained terminology ('refund-armed', 'ride_networks', 'we ride the armed chain'), so information density comes at the cost of clarity.

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

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

For a two-parameter quote tool with no output schema, the description does cover the essentials an agent needs: cost model, chains, and the returned payTo/ride_networks/total fields plus the follow-up POST. It still leaves the 'method' parameter and the custody prerequisites unexplained, so it is adequate rather than complete.

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

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

Schema coverage is only 50%: 'url' is documented in the schema as the https x402 seller endpoint, but 'method' (GET/POST) is undocumented in both schema and description. The description's {"url":...} snippet merely echoes one parameter and adds no semantics, least of all which HTTP method to choose.

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 (Quote) and resource (a BOOTH ride) and even lists the returned fields, so the operation is identifiable. However, 'BOOTH ride' and 'x402 seller' are unexplained domain jargon, and nothing in the description distinguishes this from siblings like khotem_gas_route or khotem_gate, leaving the agent to guess at the product model.

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 implies a workflow step via 'Then POST /api/booth {...} with payment', which tells the agent this is the pre-payment quote. But there is no explicit when-to-use/when-not guidance, no stated prerequisites (e.g., required custody/refund state), and no named alternative for price discovery.

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 add real context: the call itself is free, it covers the complete set of paid services (not a subset), and it specifies what the payload encodes (USD prices, EVM-family and Solana rails 'where listed'). It does not state auth requirements or rate limits, but for a zero-parameter read this is a solid disclosure.

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?

A single front-loaded sentence with the most decision-relevant fact ('FREE') first, followed by scope and payload contents. Every clause earns its place and nothing is padded.

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, annotation-free, output-schema-free discovery tool, the description conveys enough: cost, scope, and what the response contains. It stops short of explaining whether each catalog entry includes invocation details or how to proceed from catalog to a paid call, which would have made it fully self-sufficient.

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

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

The tool takes no parameters, so there is nothing to disambiguate; the baseline for a 0-parameter tool is 4. Schema coverage is 100% and empty by construction.

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 resource (the full catalog of paid KHOTEM services) and its contents (USD prices, payment rails on EVM and Solana), so an agent knows this is the discovery/listing endpoint. However, the verb is only implied (a noun phrase, not 'List/Retrieve'), and no sibling such as khotem_booth_quote or khotem_status is named to anchor the distinction.

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?

Leading with 'FREE' strongly implies the intended usage: consult this zero-cost catalog before invoking paid services. Beyond that cue there is no explicit when-to-use, when-not-to-use, or named alternative, so guidance stays at the implied level.

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 load and does so well: it discloses the price ($0.25), the bundle contents, the return (course id), and the auth mechanism (X-COURSE header with the id). It omits edge behavior such as course-id expiration, refunds, or what happens if 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?

Dense and front-loaded: the price leads, then what you get, then the returned id, then the follow-up header usage. Every clause carries a distinct piece of actionable 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 one-parameter payment tool with no annotations and no output schema, the description covers cost, scope, return value, and the follow-on usage pattern. It is nearly complete, missing only error/expiration handling that would make it fully self-sufficient.

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

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

Schema description coverage is 0% for the single payment_tx parameter, so the description must compensate. It clarifies that payment must happen before passing payment_tx, implying a transaction identifier, but gives no format or validation detail. Adequate but thin for a parameter that gates a paid action.

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?

It states the resource (a COURSE bundle) and enumerates exactly what it provides: one payment for five procedures (spa/med/attest/trust-score/seal), returning a course id. This distinguishes it from the per-call sibling tools it names. The core verb ('purchase/create a course') is only implied, which keeps it 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?

'one payment pulls 5 procedures ... zero per-call payment' implicitly tells the agent when to prefer this over paying for each sibling individually. It also sequences the workflow explicitly ('Pay first, then pass payment_tx'), giving clear ordering context, though it never states an exclusion or failure case.

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?

With no annotations, the description carries the full behavioral burden, and it does disclose a lot: paid ($0.02), pay-first-then-submit ordering, and the settlement semantics of payment_tx. It does not cover failure modes (bad tx hash, wrong payTo) or return shape beyond the one-line output promise.

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 dense sentence plus a short instruction; nothing is padding. The front-loaded 'PAID $0.02' is exactly the kind of critical fact an agent needs first. Slight demerit for stacking five chains and four output fields into a single run-on line.

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, 3-param, no-annotation, no-output-schema tool, the missing pieces matter: what each input returns, units/semantics of amount_usd and latency_weight, and error handling for payment_tx are all absent. The description is informative but not sufficient to call the tool confidently.

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

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

Schema coverage is only 33% (only payment_tx is documented), so the description must compensate. 'Pay first, then pass payment_tx' ties the payment flow to that parameter and reinforces the schema note, but amount_usd and latency_weight are left semantically dark in both places.

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 precise verb and resource ('GAS ROUTE: live settlement-cost ranking across Base/Polygon/Linea/zkSync/Scroll/Solana') with the actual output promised (cheapest rail, estimated USD per settle, savings vs Base). No sibling tool does settlement-cost ranking, so the purpose 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?

The description implies when to use it (when you need to choose a chain for a settlement) but never names an alternative or an exclusion. It also dictates a workflow ('Pay first, then pass payment_tx') rather than when-to-prefer-this-over-X. Adequate but with a clear gap on routing 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 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 must carry the full behavioral burden. It usefully discloses that the call is free and names the payment mechanisms (x402, PAYMENT-SIGNATURE/X-PAYMENT, EVM txHash vs Solana base58 signature), but says nothing about what the guide returns or its read-only nature.

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?

A single compact sentence with the cost signal front-loaded ('FREE'). It is dense and wastes nothing, though the parenthetical of protocol tokens is terse to the point of being cryptic.

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 and no annotations, the description covers the gist of the guide's topic but omits what the response actually contains (steps? text? links?) — a gap an agent would want closed before invoking.

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 there is nothing to mis-document; the baseline of 4 applies. Schema coverage is 100% and trivially so.

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 resource type (step-by-step guide) and its subject: how an agent pays and calls KHOTEM. An agent can infer this is the onboarding/payment instruction tool, distinct from the action-oriented siblings like khotem_gate or khotem_receipt, though the description never explicitly names a sibling to differentiate itself.

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 only implied: the 'FREE' marker and the payment-topic framing hint that this should be consulted before paying. There is no explicit when-to-use/when-not-to-use statement or pointer to alternatives such as khotem_start or khotem_ping.

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?

With no annotations, the description carries the full burden and does disclose the important behaviors: this is a paid call ($0.10), it uses an x402 payment flow, requires paying before passing payment_tx, runs on Base, and dedupes results by tx. It omits failure modes (what happens with an invalid/expired payment_tx), rate limits, and any freshness beyond the 24h seller window.

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 with zero filler, and the most decision-relevant fact — the $0.10 cost — is front-loaded before the data scope and the payment workflow. Nothing is padded.

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 paid data tool with no output schema and no annotations, the description covers price, protocol, chain, data scope, and the payment sequence — the main things an agent needs. It stops short of describing the payment_tx format and error behavior, which a caller of a paid gated tool would want.

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% for the single payment_tx parameter, so the description must compensate. 'Pay first, then pass payment_tx' does explain where the value comes from (a prior payment transaction), which is meaningful added semantics, but it never states the expected format (tx hash, id, chain-qualified) or whether it is validated.

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 resource and scope: 'fresh settlement intelligence on Base — new paid sellers (24h), volume leaders observed, deduped by tx.' An agent can tell this returns market/seller activity data rather than a receipt or trust score. It lacks an explicit verb and never names the closest sibling it should be preferred over, keeping it 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?

It gives one real workflow rule — 'Pay first, then pass payment_tx' — which tells the agent the call is gated behind a payment step. There is no statement of when to choose this over siblings like khotem_trust_score or khotem_agent_credit_report, and no when-not-to-use guidance, so usage 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?

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?

With no annotations, the description carries the full burden. It usefully discloses that the call is FREE, that it does a two-part check (ledger membership, then on-chain existence only for txHashes), and that output is human-readable. It omits permissions/auth, rate limits, and what failures or negative results look like.

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

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

Front-loaded with the high-value signal (FREE), then the operation and the usage cue in two tight sentences with no filler. Slightly dense parentheticals, but 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?

No output schema and no annotations, so the description is the only source of behavioral contract. It covers the operation and ref formats but not the response shape or negative-result semantics, leaving an agent guessing at what a successful check returns.

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% and the single 'ref' param is bare, but the description compensates well by enumerating accepted formats (txHash | sha256 | 16-hex stamp). This is exactly the format guidance the schema lacks, so the description adds real value over the structured field.

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 (check) and resource (a ref against the KHOTEM ledger, plus on-chain presence on Base for txHashes) and clearly scopes itself as a pre-check. It implies a distinction from the paying receipt tools but never names a specific sibling (khotem_receipt / khotem_receipt_verify), so differentiation is partial rather than explicit.

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

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

'Human-readable pre-check before paying for a portable receipt' gives clear context for when to reach for this tool versus the paid receipt flow. No explicit when-not or named alternative, but the intended moment of use is unambiguous.

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?

With no annotations, the description carries the full burden and does disclose two behavioral facts beyond the schema: the call is FREE (cost) and EVM wallets 'can ride zero-gas via facilitator'. It stops short of stating whether the tool is read-only/stateless or what happens on repeat calls, but the cost and gas disclosures are genuinely non-obvious value.

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 tight sentence, front-loaded with the 'FREE' signal and the core outcome, with no filler. The em-dash asides stay contained, though the phrasing is slightly dense.

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

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

No output schema and no annotations, so the description must explain the return, and 'get your exact state and the single next step to your first payment' roughly does so. For a 0-required-param entry point this is mostly complete, missing only whether it is stateless/side-effect-free.

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% and the single parameter is already documented as an optional 0x/base58 address. The description only restates 'EVM or Solana wallet (or none)' and adds the EVM zero-gas note, which is a marginal restatement rather than new parameter semantics. Baseline 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 gives a specific role: guided onboarding that returns your state and the single next step toward a first payment. The 'FREE' tag and 'first payment' outcome make the intent concrete without opening the schema. However, it never distinguishes itself from cryptic siblings like khotem_guide, khotem_intake, or khotem_status, so an agent can't tell which is the real entry point.

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?

'Guided onboarding' strongly implies this is a first-step tool, and '(or none)' signals the wallet is optional, which is a useful invocation cue. But there is no explicit when-not guidance and no routing to alternatives among the many similarly named siblings.

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.

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 real traits: deterministic behavior, a fixed output form ('one line of reason'), cost ('FREE'), and an explicit prompt-injection stance ('inputs treated as untrusted data, never instructions'). It still omits whether the call has side effects, is idempotent, or requires auth, which matters for a verdict endpoint.

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

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

Front-loaded with 'FREE.' followed immediately by the purpose, then constraints. Dense but each clause adds something; the inline brace list of parameters is mildly redundant with the schema but still functional.

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

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

No output schema and no annotations, so the description must stand alone; it covers purpose, output form, cost and safety but leaves required-vs-optional parameters, error/edge behavior, and whether a verdict is persisted unspecified. Adequate but with visible gaps for a 6-parameter tool.

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

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

Schema coverage is 0% and there are 6 parameters, so the description must compensate. It enumerates all six names and implicitly maps them ('the task as published' vs 'a delivered task result'), which helps, but it never marks taskId/attemptId as required or explains the untyped `input` and `result` payloads.

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: 'decide accepted/rejected for a delivered task result against the task as published', which is concrete and actionable. The 'verdict endpoint' framing plus the one-line reason clarifies the deliverable. It does not differentiate itself from opaque siblings like khotem_gate or khotem_seal, so it stops 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 says what inputs the endpoint consumes but never states when to call it versus alternatives, nor any preconditions such as the task having been published or an attempt already existing. With 23 sibling khotem_* tools and no routing hint, the agent gets no selection guidance.

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