k402

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

No annotations provided, so description carries full burden. Discloses cost and public accessibility, but does not mention error conditions, rate limits, or behavior on invalid input.

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

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

Two sentences front-loading the action and output. No filler words; every word adds value.

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

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

Provides core purpose and cost, but missing details on parameter constraints, error handling, and return value structure (though output format is hinted). Adequate for a simple tool but not fully comprehensive.

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%. The description only implies parameters through action ('verify against an image_id') but does not add format, constraints, or examples beyond the names.

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

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

Description clearly states the action ('verify'), the resource ('RISC Zero receipt against an image_id'), and the output format ('{valid, journal_b64}'). Distinguishes from sibling 'prove_*' tools by focusing on verification.

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?

States that anyone can use it without trusting the prover and mentions cost (~$0.0002), giving context on when to use. However, no explicit comparison to other tools or when not to use.

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

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

No annotations provided, so description must cover behavioral traits. It clearly states it lists services with live prices, is free, and is a read-only operation. No mention of return format, but given no parameters, the behavior is well-described.

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

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

Two sentences, no fluff, front-loaded with the main action and key attributes. Every sentence adds value.

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

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

Given zero parameters and no output schema, the description is fully complete. It tells what the tool does, that it's free, and its role as a starting point. No gaps.

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

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

Zero parameters, so schema coverage is 100%. The description adds meaning by specifying the output content (list of services with prices), which is valuable beyond the empty input schema. Baseline for 0 params is 4.

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

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

The description uses specific verb 'List' and resource 'every service this gateway sells' with additional details (live prices in KAS/USD, free). It clearly distinguishes from sibling tools by being an overview/introductory tool.

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

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

Explicitly says 'Start here to see what's available and what calls cost,' indicating it's the first tool to use. Does not explicitly mention when not to use or alternatives, but the context from sibling tools implies its role.

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

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

With no annotations provided, the description fully discloses behavioral traits: it is free, returns specific fields, and indicates error behavior. It explains the underlying trustless covenant-enforced mechanism and notes that the user's Kaspa key is needed for actual channel opening, implying no destructive side effects.

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

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

The description is front-loaded with purpose ('Parameters for opening a kaspa-channel') and efficiently conveys key information. It is somewhat verbose (e.g., redundant explanation of trustless nature), but each sentence adds value, making it clear and usable without excess.

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

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

Given the tool has no parameters and no output schema, the description provides complete context: what it returns, when to use it, its experimental nature, and a pointer to the client library for actual channel creation. It is sufficient for an agent to select and invoke this 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?

The input schema has zero parameters (100% coverage), so the baseline is 3. The description adds strong meaning by listing the returned fields (payee pubkey, min/max channel size, required expiry lead, maxfee) and explaining the tool's context, which is essential since no output schema is provided.

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

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

The description clearly states the tool's purpose: returning parameters for opening a kaspa-channel. It specifies the returned fields (payee pubkey, min/max channel size, required expiry lead, maxfee) and contrasts it with a custodied prepaid session, differentiating from sibling tools like covenant_build that actually create covenants.

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

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

Explicitly mentions the tool is for querying configuration before opening a channel, and directs users to the Python client for the actual covenant-building and signing flow. It also notes that an error is returned if the experimental channel rail is not enabled. However, it does not explicitly compare to other tools such as channel_status or covenant_config.

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

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

With no annotations, the description carries full burden. It lists what information is returned but omits behavioral details such as error handling, performance implications, or what happens for invalid channel IDs. 'Free' hints at zero cost but is not a thorough behavioral 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?

The description is a single, dense sentence that efficiently conveys purpose and return fields. It could be slightly more structured (e.g., bullet points) but is free of fluff and front-loaded.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description adequately covers basic functionality and returned data. However, it lacks information on error conditions, performance, and any prerequisites, leaving some gaps.

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

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

The schema has 0% description coverage, so the description must compensate. It clarifies that channel_id is a covenant ID, adding meaning beyond the schema's type/name. However, it does not specify format, validation rules, or example values.

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 retrieves status of a kaspa-channel by its covenant id, listing specific fields (funded value, amount spent, remaining, expiry, closed status). This distinguishes it from siblings like channel_config or covenant_check.

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 explicit guidance on when to use or not use this tool, nor comparisons with alternatives like channel_config or covenant_check. The description only implies usage when channel status is needed, but lacks context about prerequisites or exclusions.

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

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

With no annotations provided, the description discloses important behavioral traits: the multi parameter behavior, label count constraint (2-32), and cost. This adds significant value beyond the bare schema.

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

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

The description is two sentences, front-loading the core purpose, and contains no redundant information. Every word contributes meaning.

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 lacking output schema, the description covers key aspects: input parameters (partially), constraints, and cost. It is sufficient for an AI agent to understand basic usage, though return format and error handling are omitted.

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

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

Schema coverage is 0%, so the description must compensate. It explains the 'multi' parameter and labels constraint, but does not describe the 'text' parameter in detail (e.g., length limits or encoding). Partial compensation.

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 verb 'classify' and the resource 'text', specifies the range of labels (2-32), and mentions multi-label capability. This effectively distinguishes it from sibling tools like 'generate' or 'summarize'.

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 use for classification with predefined labels, but does not explicitly state when to use this tool over alternatives or provide exclusions. The context is clear but guidance is 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?

Discloses cost (~$0.0003) and valid networks. No annotations provided, so description carries burden. Missing details on error handling, return value, or what constitutes a valid compiled script.

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

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

Two sentences, no filler. Essential information front-loaded: action, resource, networks, cost.

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

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

With 2 parameters, no output schema, and paid tool, description covers basics but omits expected output format, prerequisites for script_hex, and any constraints. Could be more complete for agent decision-making.

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 0%, so description adds value by mentioning 'compiled script' for script_hex and specifying networks. However, lacks format details for script_hex and complete network enumeration.

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

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

Clearly states the action (derive) and resource (covenant P2SH address) with network options. Differentiates from sibling tools like covenant_broadcast, covenant_build, etc., by focusing on address derivation.

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 explicit guidance on when to use this tool versus alternatives. Context hints at post-compilation usage but lacks direct comparison or exclusions.

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

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

Discloses that the tool moves real KAS and costs approximately $0.0003, adding behavioral context beyond the lack of annotations. No contradictions with annotations (none provided).

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 concise sentences, front-loaded with the action and input source. Every sentence adds value without redundancy.

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

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

The description covers the core action and key warnings but omits return value details (e.g., transaction ID) and error handling. Given the complexity of a nested object and no output schema, more completeness would be beneficial.

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

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

Description clarifies that the 'transaction' parameter expects a 'RpcTransaction JSON from covenant_build', adding meaning beyond the schema. However, the 'network' parameter is not explained beyond its default value. With 0% schema coverage, the description should compensate more thoroughly.

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

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

Clearly states the action 'Broadcast a signed covenant tx' and specifies the input format as 'RpcTransaction JSON from covenant_build'. Differentiates from siblings like covenant_build and covenant_check by describing the broadcast step.

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

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

Explicitly advises to 'run covenant_check first' and warns that 'MAINNET moves real KAS', providing clear context for when to use. Lacks explicit when-not-to-use but the guidance is strong.

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

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

With no annotations, the description carries full burden. It states 'We never sign,' discloses paid usage, and lists return components (tx, rpc_transaction, fee accounting, pre-verify). It does not discuss error scenarios or idempotency.

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

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

The description is a single dense paragraph that efficiently conveys core information. It is front-loaded with purpose, but slightly lacking in structure (e.g., bullet points would improve readability).

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

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

Given 5 parameters and no output schema, the description covers the main behavioral aspects and return values. However, it misses details on optional parameters and error handling, which would improve completeness.

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

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

Schema coverage is 0%, so description must explain parameters. It thoroughly explains the `inputs` and `outputs` array structures, but omits description of `network`, `lock_time`, and `payload_hex`, which have defaults but are not trivial for all users.

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 'Assemble a covenant spend tx' and provides detailed structure for inputs/outputs, distinguishing it from siblings like covenant_broadcast and covenant_address.

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 instructions on input and output structure, including optional fields and conditional logic (e.g., sigscript vs P2PK). However, it does not explicitly contrast with other covenant tools or provide when-not-to-use 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 full burden. It describes the local verification behavior, return structure, cost, and input format. Could mention absence of side effects or failure handling more precisely, but overall adequate.

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

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

Two sentences plus return type and cost: every part earns its place, front-loaded with purpose and key detail. No redundancy.

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

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

Given nested objects and no output schema, description covers input, behavior, output structure, and cost. Missing error details but sufficient for an AI agent to use 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 description coverage is 0%, but the description explains 'entries' as spent UTXOs and references 'covenant_utxos' output. The 'transaction' parameter is implied but not detailed; still adds significant meaning beyond schema.

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

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

The description clearly states the tool performs local pre-verification of a signed covenant transaction before broadcast, using the verb 'pre-verify' and resource 'signed covenant tx'. It distinguishes from sibling tools like 'covenant_broadcast' and 'covenant_build' by explicitly framing it as a pre-broadcast check.

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

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

Explicitly advises use before broadcast to catch script failures, providing clear context. However, it does not explicitly mention when not to use or name alternatives, though siblings are listed in context.

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

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

Despite no annotations, the description adds valuable behavioral context: it notes the call is paid (~$0.002) and clarifies that 'compiles' ≠ proven on-chain. This goes beyond basic functionality.

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 very concise: two sentences plus a brief note. Every part adds value, starting with the action verb 'Compile'.

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?

Without an output schema, the description hints at outputs (script hex, ABI, etc.) but does not explicitly state the return format or that these are the response fields. Slightly incomplete for a compile tool.

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

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

The description explains <code>constructor_args</code> as 'the silverc ctor JSON' with an example, adding meaning that the schema alone (with 0% coverage) does not provide. The source parameter is also implied by the verb 'compile'.

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

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

Description explicitly states it compiles a Silverscript covenant to script hex, ABI, hardened template hash, and P2SH address on each network. This clearly distinguishes it from siblings like 'covenant_address' or 'covenant_broadcast'.

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 lacks explicit guidance on when to use this tool versus alternatives. It implies usage for compilation but does not mention when not to use it or suggest other tools for different stages.

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

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

Discloses it's live data from the node and costs about $0.0003, indicating it's a paid call. No annotations exist, so the description should cover idempotency, rate limits, or side effects, but it does not. The cost mention is helpful but insufficient.

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 concise sentences with front-loaded purpose. No unnecessary details, making it efficient for an agent to parse.

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

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

Provides basic purpose and cost, but lacks details on output format, error handling, and the meaning of 'covenant state inspection'. The network parameter omission is a 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 description mentions the address (implied) and covenant_id filter, but ignores the 'network' parameter entirely. With 0% schema description coverage, the description fails to fully compensate for the missing schema documentation.

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

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

The description clearly states it retrieves the live UTXO set locked under a covenant address for inspection. It mentions optional filtering by covenant_id, distinguishing it from related tools like covenant_address or covenant_build.

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?

Implies usage for inspecting covenant UTXOs and notes it's paid, but does not explicitly state when to use vs alternatives (e.g., covenant_check) 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?

Without annotations, the description provides model name, output dimensions, max count, and cost. However, it omits idempotency, error behavior, and authentication requirements.

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

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

Single sentence with no filler, front-loading key information (action, limit, model, cost).

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 tool with no output schema, it describes output dimensions and cost, which is helpful. Could explicitly mention return format (array of embeddings), but largely complete.

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

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

Schema coverage is 0%, so description must compensate. It adds only a max count constraint ('up to 64 texts') but no further semantics like text preprocessing or encoding.

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

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

The description clearly states the action ('Embed'), the resource ('texts'), and specifies output dimensions ('768-dim vectors') and model ('nomic-embed-text'), distinguishing it from siblings like classify or summarize.

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 on when to use this tool versus alternatives (e.g., search_index, classify). It only mentions a cost but lacks context for decision-making.

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 responsibility. It discloses the cost and guaranteed schema-constrained decoding, but does not mention side effects, authentication needs, rate limits, or error handling behavior. The guarantee is stated but lacks details on failure cases.

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 with two sentences. The first immediate sentence states the core purpose and guarantee, and the second adds cost. Every word earns its place; no unnecessary details.

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

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

Given no output schema, no annotations, and 33 sibling tools, the description is somewhat incomplete. It covers purpose and cost but lacks usage guidelines, parameter details for the instruction parameter, and behavioral traits beyond the guarantee. For a tool of moderate complexity, it is adequate but not comprehensive.

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 description only references 'JSON schema' implicitly. The 'text' and 'schema' parameters are clear from context, but the optional 'instruction' parameter is not mentioned at all, leaving its purpose unclear. The description adds minimal value beyond the schema itself.

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

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

Description clearly states it extracts structured data from text as JSON matching a provided schema, using schema-constrained decoding. It specifies the verb 'extract' and resource 'structured data from text', distinguishing from alternatives by emphasizing guaranteed schema compliance and mentioning it's paid.

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 explicit usage guidelines or alternatives are mentioned. The phrase 'not best-effort' implies a contrast with generic extraction, but does not specify when to use this tool versus siblings like classify or generate. The agent must infer usage from context, which is minimal.

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

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

No annotations are provided, so the description must disclose behavior. It mentions costs and tier details but omits critical traits: rate limits, idempotency, side effects, or whether payment is required upfront. The tool likely requires an active session or credits, but this is not stated.

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

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

The description is efficient, conveying core purpose and tier details in two sentences. It front-loads the action and list. Minor waste: cost details could be in a separate field, but overall concise for the information density.

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

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

Given no output schema and 0% parameter coverage, the description should be more comprehensive. It lacks return format (just 'completion text'), edge cases, or dependency on other tools (e.g., 'open_session'). The context signals indicate a simple tool, but key behavioral and usage gaps remain.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to the 'tier' parameter by listing options and costs. However, it does not explain 'system' (system prompt) or 'max_tokens' (output length), leaving half the parameters undocumented. The 'prompt' parameter is self-explanatory from its name.

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

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

The description clearly states it runs a prompt on GPU model tiers and returns completion text. It lists specific model options with costs, making the purpose concrete. However, it does not explicitly distinguish from sibling tools like 'catalog' or 'classify', though the generation intent is 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?

No explicit guidance on when to use this tool vs alternatives. The description lists tiers with costs but doesn't explain when to pick which tier or when not to use this tool (e.g., for classification). Lacks context about prerequisites like authentication or session management.

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

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

Discloses 404-not-found behavior until completion, 24-hour retention, and cost. No annotations provided, but description covers essential behavioral traits for a simple fetch tool.

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

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

Two sentences, no wasted words. Purpose and key details front-loaded efficiently.

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?

Sufficient for a simple tool: explains behavior, retention, cost. Could add where job_id comes from, but not essential given sibling context.

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

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

Only parameter job_id has no description in schema or description. With 0% schema coverage, description should elaborate on job_id meaning or provenance, but it does not.

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

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

Clearly describes fetching a finished proving job's result with specific fields. Distinguishes from sibling tools like job_status and prove_submit.

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?

States when to use (after job is finished) and includes key constraints ('404 until done', 'results kept 24h', 'Free'). Lacks explicit alternatives but context is clear.

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

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

While it states the tool is free and returns status information, it does not disclose if the operation is read-only, rate limits, or authentication needs. No annotations exist to cover these 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 a single, well-structured sentence that efficiently conveys core information without unnecessary words.

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

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

Given the simplicity of the tool (1 param, no output schema, no annotations), the description is incomplete—missing details on job_id source, error handling, and whether polling is synchronous.

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 description provides no explanation for the 'job_id' parameter; schema documentation coverage is 0%, so the description fails to add any semantic meaning about what job_id is or how to obtain it.

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 polls a proving job, listing possible statuses and returned data (queue position, cost). It distinguishes from sibling tools like 'job_result' by specifying 'poll' for status tracking vs. result retrieval.

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

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

The description implies usage for checking job status and notes the tool is free, but lacks explicit guidance on when to use this vs. alternatives like 'job_result' or when polling should stop.

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

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

With no annotations, description provides cost information and architectural detail (no indexer/API key). But does not disclose error handling, return format, or other side effects. Adequate but not rich.

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 concise sentences that front-load the purpose and key details (network, payment). No wasted words.

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

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

For a simple balance check with one parameter and no output schema, description covers essentials: network, cost, no dependencies. Could optionally mention return value format (e.g., balance in KAS), but overall 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 has one parameter 'address' with 0% description coverage. Description adds that it is for a Kaspa MAINNET address, providing minimal semantic context beyond the schema. No format or examples given.

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

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

Description clearly states it retrieves the balance of any Kaspa MAINNET address, distinguishing it from sibling tools like fee estimates and transaction status. Verb 'Balance of' and specific resource make 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?

Description notes direct node access, no API key needed, and cost, implying straightforward use for balance queries. However, lacks explicit guidance on when to use vs alternatives or when not to use.

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 mentions 'Paid' implying a cost, but does not explain the cost mechanism, whether it consumes credits, or any side effects. No disclosure of read-only nature or required auth.

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?

Extremely concise—two sentences, no fluff. Every word contributes to the purpose. For a simple tool, this is ideal.

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

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

Despite no output schema, the description fails to define what a 'feerate bucket' is (e.g., list of objects with feerate and label). The 'Paid' detail is vague and incomplete. An agent would not know what the tool returns or the exact cost implication.

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

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

No parameters exist, so schema coverage is 100%. The description adds value by explaining the output (feerate buckets, units) beyond the schema. Baseline is 4 for zero-parameter tools.

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 retrieves current Kaspa mainnet feerate buckets in sompi per gram of tx mass, which is specific and distinct from sibling tools. However, the phrase 'Paid (~$0.00015)' is ambiguous and slightly detracts from clarity.

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

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

No guidance on when to use this tool versus alternatives (e.g., kaspa_balance, kaspa_network). The description lacks any context about prerequisites, when not to use, or recommended scenarios.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool is paid, which adds transparency. However, it does not mention rate limits, update frequency, or other behavioral aspects. The description is adequate but not comprehensive.

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

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

The description is extremely concise at two sentences, with the purpose front-loaded in the first sentence and cost information in the second. No unnecessary words.

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

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

For a zero-parameter tool with no output schema, the description provides a reasonable list of returned data (DAA score, block count, difficulty, node sync state). It could benefit from indicating the output format or any pagination, but it is largely complete.

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

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

There are no parameters, so baseline is 4. The description adds no parameter information, but the schema coverage is 100% given no parameters. The description's mention of the status fields compensates slightly, but no extra meaning 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 states the tool provides Kaspa mainnet status with specific metrics (DAA score, block count, difficulty, node sync state). It implicitly distinguishes from sibling tools like kaspa_balance or kaspa_fee_estimate, but lacks explicit differentiation.

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

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

The description mentions the cost, which provides some context, but does not specify when to use this tool over alternatives or when not to use it. Usage guidance is minimal.

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 the behavior for absent transactions and mentions the fee. This is adequate for a simple read-only status check, though it doesn't specify error handling or input validation.

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

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

The description is two sentences, immediately stating the core function and key behavioral note. No unnecessary words; every sentence provides distinct value.

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

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

Given the tool's simplicity (1 param, no output schema), the description covers the essential: purpose, interpretation of absence, and cost. The mention of the sibling tool kaspa_utxos provides a complete workflow context. Minor gaps like input format are acceptable.

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 should compensate. However, the only parameter 'txid' is self-explanatory as a transaction ID. The description adds no format or example, but the param's name and context make it clear enough. A 3 is appropriate given minimal added value.

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 checks mempool status of a Kaspa transaction. The verb 'status' is somewhat generic but the context 'mempool status' specifies the resource. It distinguishes itself by referencing the alternative action for absent transactions via kaspa_utxos.

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

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

The description explicitly tells when to use the tool and when to use alternatives: 'Absent from mempool means accepted-or-unknown — confirm acceptance by checking one of its outputs with kaspa_utxos.' It also notes the cost (~$0.00015), which aids decision-making.

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

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

Discloses that the tool is paid (~$0.0003 in KAS), which is useful behavioral information. No annotations provided, so description carries full burden. Missing details on side effects, rate limits, or data freshness.

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 short sentences, no redundant language. Clearly states purpose and cost, earning 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 simple tool with one parameter and no output schema, the description covers the basic purpose and cost. However, it lacks details on return format, error handling, and differences from sibling tool 'covenant_utxos'.

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%, meaning no parameter descriptions in schema. The description adds no additional meaning for the sole 'address' parameter beyond its name, failing to specify format or examples.

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

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

The description clearly states the tool returns the UTXO set for a Kaspa mainnet address, specifying included fields. However, it does not differentiate from the sibling tool 'covenant_utxos', which likely has overlapping functionality.

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

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

No guidance on when to use this tool versus alternatives like 'covenant_utxos' or other address-related tools. No mention of prerequisites or context where this tool 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 full burden. It discloses that the tool is free, requires a minimum deposit of 0.25 KAS, that deposits become spendable within seconds, and that the session is saved locally. It does not cover potential failure modes or session expiration, but for a simple creation tool, this is sufficient.

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

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

The description is concise (4 sentences), front-loaded with the main purpose, and every sentence provides unique value. No redundant or filler content.

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

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

Given no output schema, the description explains the return values (session key, deposit address) and the deposit mechanics. It covers the key aspects needed to use the tool, though it could mention session persistence or recovery if the local storage is cleared.

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

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

The input schema has zero parameters, so the description naturally cannot add parameter meaning beyond the schema. Baseline 4 is appropriate as per guidelines for 0-param tools.

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 verb 'Open' and the resource 'prepaid payment session', and specifies the outputs (session key, deposit address). It distinguishes from siblings like 'use_session' and 'session_status' by establishing this as the session creation step.

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

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

The description implies usage context: before making paid tool calls and to obtain a deposit address. It mentions 'every paid tool call meters against it', indicating when to use. However, it does not explicitly state when not to use (e.g., if a session already exists), though the local save mechanism hints at automatic reuse.

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

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

No annotations are provided, so the description bears the burden of behavioral disclosure. It states the tool is free and lists accepted payments, implying it is a read-only query. However, it does not explicitly mention idempotency or lack of side effects.

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

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

The description is informative but somewhat lengthy. It front-loads the main purpose and uses bullet points effectively, but could be slightly more concise without losing detail.

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 0-parameter tool with no output schema, the description is very complete. It covers return content, lists specific coins, references sibling tools for payment methods, and even mentions experimental features.

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

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

The tool has zero parameters and the schema coverage is 100%. The description adds meaning by explaining the output (coins and schemes) and how it relates to other payment tools, providing context beyond the schema.

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

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

The description explicitly states 'Which coins and schemes this gateway accepts for payment', making the purpose clear. It distinguishes itself from sibling tools by listing payment methods that reference open_session, pay_per_call, and channel_config as alternatives.

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

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

The description explains the tool's role in the payment workflow, noting it is free and listing the coins/schemes. It implicitly guides when to use it (to discover payment options) but does not explicitly state when not to use it.

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

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

With no annotations provided, the description carries the full burden of disclosure. It explains the entire flow: prerequisite 402, on-chain payment, parameter requirements, and gateway verification returning the real result. However, it does not mention error handling, rate limits, or authorization needs.

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 paragraph of three sentences, efficiently front-loading the purpose, then describing the workflow, and finally contrasting with an alternative. Every sentence adds value with no redundancy.

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

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

Given the complexity (5 required params, nested object, no output schema), the description covers the main workflow and parameter sources. However, it lacks details on return value format, error scenarios, and potential failure cases, making it only moderately 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?

The input schema has 0% description coverage, so the description must provide meaning. It does so by explicitly mapping each parameter to its source: endpoint and request_body from the 402, scheme and payment_id from the chosen offer, and txid from the user's payment. This adds significant semantic value, though formats or constraints are not detailed.

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 completes a PER-CALL coin payment, explains the workflow involving a 402 response and on-chain payment, and distinguishes itself from prepaid sessions by stating it's an alternative when paying each call directly in a specific coin.

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

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

The description provides clear context on when to use the tool: after a paid tool returns a 402 with offers, and as an alternative to a prepaid session. It specifies the sequence of steps but does not explicitly list exclusion conditions or other alternatives beyond 'prepaid session'.

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 key behavioral traits: it returns a content-addressed image_id (also verification key), is reusable, and costs money. It also implies the binary is uploaded in base64. It lacks details on idempotency or what happens on duplicate uploads, but is adequate.

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 sentence under 150 characters. It front-loads the action 'Upload a RISC Zero program binary' and includes all critical details (base64, return value, reusability, cost) without redundancy. Every word serves a purpose.

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

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

Given the tool has one parameter and no output schema or annotations, the description adequately covers what it does, what it returns, and that it costs money. It could mention potential errors or limits, but for a simple upload tool, it is fairly 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?

The parameter 'program_b64' has 0% schema description coverage but the description adds meaning by specifying 'the .bin risc0-build emits, base64'. This clarifies the expected format beyond the schema's 'string' type. The description thus compensates well.

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 verb 'Upload', the resource 'RISC Zero program binary', and the output 'image_id'. It distinguishes itself from sibling tools like prove_submit and prove_preflight by focusing on the upload step. The inclusion of 'reusable across proofs' further clarifies its role.

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 is for uploading a program once before generating proofs, which guides usage. It mentions 'Paid (~$0.01)', providing cost context. However, it does not explicitly compare to alternatives or state when not to use it.

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

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

With no annotations, the description carries full burden. It discloses that the tool is paid, does not perform proving, and returns specific data. However, it omits details about side effects (e.g., whether the guest execution is persisted) or prerequisite actions.

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 very concise with two effective sentences and a structured output hint. It is front-loaded with the core action, and every part adds value without waste.

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 2 parameters and no output schema. The description covers the return value and pricing but lacks explanation of parameters and prerequisites (e.g., guest upload). It is adequate but leaves gaps for an agent to fully understand usage.

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

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

Schema description coverage is 0%, so the description must compensate. It does not mention or explain either parameter (image_id, input_b64), offering no added meaning beyond the schema. This is a significant gap.

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 executes a guest without proving and returns cycle count and price quote. It uses a specific verb 'Execute' and resource 'guest', and distinguishes from siblings by indicating 'Run this first' before proving steps.

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 advises to run this tool before proving because cost scales with cycles, and mentions it is paid (~$0.002). While it does not explicitly list alternatives, the context implies it's a preflight to estimate cost, which guides when to use.

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

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

With no annotations, the description carries full burden. It discloses dynamic pricing, refusal if over max_kas cap, and return structure. However, it omits auth needs, side effects, or error handling.

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

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

Three sentences with no waste. First sentence states purpose and output, second details parameters, third mentions pricing. Front-loaded and efficient.

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

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

Given no output schema, the description provides return shape and references related tools. It covers key behaviors but lacks error types or cancellation info. Adequate for a complex tool.

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

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

Schema coverage is 0%. Description adds meaning for quote_id and max_kas (usage scenarios), but does not explain image_id or input_b64. Hence partially compensates but remains incomplete.

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

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

The description starts with 'Queue a proving job' which is a specific verb and resource. It clearly distinguishes from siblings like prove_preflight (for quotes) and job_status/job_result (polling results).

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

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

The description explains when to use quote_id (from prove_preflight) vs max_kas (skip preflight) and mentions follow-up steps (poll job_status, fetch job_result). It lacks explicit 'when not to use' but provides clear context.

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

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

No annotations provided, so description carries full burden. It discloses read-only nature, output format, and cost. Lacks details on rate limits, site restrictions, or caching behavior.

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

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

Two sentences, no redundancy. Front-loaded with core purpose, secondary information (cost) placed after. Every sentence adds value.

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

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

For a simple tool with 2 params and no output schema, description covers main functionality and optional parameter but lacks precise return structure (e.g., JSON, text). Cost info is a good addition.

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 has 0% description coverage; indeed no descriptions in schema. Description compensates by explaining 'url' implicitly and 'distill' explicitly. Does not detail URL format requirements.

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

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

The description uses specific verb 'fetch' and resource 'public web page', clearly stating output: title + clean markdown with optional distillation. It distinguishes from sibling tools, none of which perform similar web fetching.

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

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

The description provides clear context: 'Useful when you have no web access of your own' and includes cost. No explicit exclusions or alternatives are mentioned, but the context is sufficient.

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

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

No annotations exist, so the description must fully disclose behavior. It mentions cost (~$0.001 in KAS) but omits details on determinism, input length limits, or side effects.

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

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

The description is a single sentence plus cost note, with no wasted words. Essential information is front-loaded.

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

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

For a simple 2-param tool without output schema, the description is adequate but leaves gaps like expected instruction format and output traits. More detail would improve completeness.

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

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

With 0% schema description coverage, the description provides only minimal context for the two parameters ('text' and 'instruction'), lacking format constraints or examples beyond broad categories.

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 rewrites text based on an instruction, with examples of tone, format, and length changes. It is distinct from sibling tools like summarization or extraction.

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 use for text modification but does not explicitly contrast with alternatives like summarize or extract. No when-not or prerequisite guidance is 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 provided, the description carries full burden. It discloses cost and security considerations but lacks details on behavioral traits such as whether operations are idempotent, what happens on duplicate collection names, or side effects of the 'replace' parameter. The description is insufficient for a mutation 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?

The description is three sentences with no wasted words. It is front-loaded with the core purpose, followed by security and cost notes. Every sentence adds value.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description provides the basic purpose and cost but lacks detail on return values, error handling, and how this tool relates to siblings like 'search_query'. It is minimally adequate but has notable gaps.

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

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

Schema description coverage is 0%, so the description must add meaning. It describes the documents format as '[{id, text, meta?}]' and mentions 'named server-side collection' for the collection parameter, but does not explain the 'replace' parameter or its default behavior. Partial coverage lifts it above baseline for low coverage.

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

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

The description clearly states the tool's purpose: 'Store documents ... in a named server-side collection for semantic search.' It uses a specific verb (store) and resource (documents in collection) and implicitly distinguishes from the sibling tool 'search_query' which is for querying.

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 advice on usage ('Use an unguessable collection name and keep it secret') and cost ('Paid (~$0.0015 in KAS)'), but does not explicitly state when to use this tool versus alternatives like 'search_query'. Usage context is implied but without exclusions or explicit 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. It discloses that it performs semantic search, returns top-k with scores, and is paid. It lacks details on authentication or side effects but is adequate for a straightforward read-only tool.

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

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

Two sentences front-load the core purpose and add critical cost info. Every word serves a purpose, making it highly concise.

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

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

Despite the tool's simplicity, the description fails to explain parameters (especially 'q' and 'top_k') and return format. With no output schema, this omission degrades completeness. The cost and prerequisite are mentioned, but not enough for full usability.

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 only hints at 'collection' but does not describe 'q' or 'top_k'. No parameter details are added beyond the schema's basic titles.

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

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

The description clearly states it performs semantic-search on an indexed collection and returns top-k matches with scores. This specific verb-resource combination differentiates it from sibling search_index, which is for indexing.

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 prerequisite of having indexed the collection and notes the paid cost, giving context for when to use. However, it does not explicitly state when not to use or suggest alternatives like exact search.

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

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

With no annotations, the description carries full burden. It describes the tool as a read-only check ('Check the current payment session'), which is transparent. However, it does not disclose behavior if no session exists or any other edge cases.

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

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

The description is one efficient sentence that conveys the purpose, output, and cost. No extraneous words.

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

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

For a zero-parameter tool with no output schema, the description adequately covers what the tool does and returns. It could mention that an active session is required, but this is implied.

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

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

No parameters in input schema, so baseline 4. The description adds no parameter info, which is acceptable as none exist.

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

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

The description clearly states it checks the current payment session and lists what it returns (deposit address, deposited/spent/remaining KAS). This distinguishes it from siblings like open_session and use_session.

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 implicitly tells when to use (to check session status) and notes it's 'Free.' It does not explicitly state when not to use or suggest alternatives, but the context is clear.

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

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

No annotations; the description only discloses cost. Missing details on parameter handling, response format, limits, or failure behavior.

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

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

Two concise sentences: purpose with constraint and cost information. No extraneous content.

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 simplicity, lacks essential behavioral context such as parameter usage, output format, and limitations, given no output schema or annotations.

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

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

With 0% schema coverage, the description should explain url, text, and max_words. It only mentions max_words, leaving exclusivity of url/text unclear.

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 summarizes text or a public URL with a max_words constraint, distinguishing it from siblings like 'extract' or 'read_url'.

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 on when to use versus alternatives or prerequisites. Mentions cost but no context on when not to use.

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?

Describes return value (session's current balance) and cost behavior ('free'), but does not mention error handling or invalid key behavior. With no annotations, adds meaningful behavioral context.

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

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

Two sentences, no wasted words, all information relevant and front-loaded. Efficient and clear.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, usage context, return value, and cost. Complete for agent decision-making.

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?

Single 'session' parameter is described as 'existing k402 session key' in description, adding meaning beyond the type string. Schema coverage is 0%, so description compensates well.

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

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

Clear verb 'attach' and resource 'session key' with explicit purpose of metering paid calls against balance. Distinguishes from sibling 'open_session' by focusing on reusing an existing key.

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

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

Explicitly says 'use after reconnecting to the hosted endpoint, or to carry one funded session across clients', providing specific when-to-use guidance without needing exclusionary language.

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