Agentic Keychain

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the evaluation uses the same method and ak.offer.v1 offer shape as evaluate_capability, which is useful consistency context, but says nothing about cost, side effects, or result semantics beyond what annotations imply.

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 tight sentence with zero redundancy, front-loading the scope constraint (2-5) ahead of the parity reference. Nothing is wasted.

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 7-parameter tool with nested objects and no output schema, the description is thin. It never explains what the comparison produces or how cost/confidence constraints affect the outcome, and it defers heavily to the sibling for the shape, leaving notable gaps for an agent to fill in.

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 71%, below the 80% baseline, so the description should compensate but only partially does. It clarifies the capabilities cardinality (2-5) and that all capabilities share the same context inputs, but the other params (task, model, constraints, expected_runs, baseline_cost_estimate) are not elaborated in the description and remain sparsely documented.

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 (assess), resource (capabilities), and scope (2-5 expected, side by side for the same inputs), and anchors the result shape to the sibling evaluate_capability. An agent can distinguish this as the multi-capability comparison variant, though it leans on the sibling for the actual meaning of the output.

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 trigger condition (comparing multiple capabilities on identical inputs) and hints at the single-capability alternative by referencing evaluate_capability for parity. However, it never explicitly says when to use this vs. evaluate_capability or when to avoid it, leaving the agent to infer the choice.

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?

Annotations already declare a safe, idempotent, closed-world read, so the safety profile is covered. The description adds that output is interval-based and conditionally limited to measured models, which is genuinely useful, but it says nothing about determinism, whether unmeasured models error or return nothing, or any quota/auth constraints.

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

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

A single dense sentence with no filler, and the per-model scoping is front-loaded. It is compact but relies on terse enumeration ("with intervals") rather than a clearly prioritized statement of the primary result.

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

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

With no output schema, the description must carry return semantics; it does list the returned quantities, which is the most important part. Still missing are what happens for unmeasured models, output units/format, and whether baseline_cost_estimate_usd is required for net-savings figures.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema with examples, formats, and bounds. The description only restates the expected_runs role and the measured-model condition, adding negligible meaning beyond the schema; baseline 3 is appropriate.

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

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

The description names the concrete computation outputs (expected saving per run, break-even runs, net saving over expected_runs, with intervals), which makes the tool's purpose inferable as an ROI estimation over a capability. However, the verb/action is carried mainly by the title, and nothing distinguishes it from siblings like evaluate_capability or compare_capabilities.

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?

"Savings are reported only for measured models" implies you must supply a model that has been measured and that results are partial otherwise, which is useful context. But there is no explicit statement of when to reach for this tool versus evaluate_capability, compare_capabilities, or get_quote, and no prerequisites such as needing a baseline cost are given here.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the agent knows this is a safe, repeatable read that does not contradict the purchase-decision framing. The description adds useful behavior context by naming the decision payload, the four evidence kinds and the offer shape, plus the constraint that verdicts come from registry-run benchmarks only. It says nothing about latency, rate limits, or the human-approval requirement that governs any resulting purchase.

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 purpose is front-loaded in the first clause, which is good, but the second half is a dense run-on enumeration of return fields ('decision, expected effect, price, confidence, reasons, operator_message, next steps and an ak.offer.v1 offer (...)'), which is hard to parse and competes with the actionable call guidance in the final sentence.

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

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

With no output schema, the description must carry return-value disclosure, and it does list the top-level fields and the offer structure. However, it gives no indication of the shape or format of those values, and for an 8-parameter tool with nested objects it omits prerequisites such as the standing human-approval rule that determines whether a positive verdict can actually be acted on.

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 high (88%), so the baseline would be 3, but the description adds real meaning by telling the agent that model, expected_runs and baseline_cost_estimate_usd together produce a money estimate and that savings are reported only for measured models. This makes those optional parameters actionable rather than incidental. The nested constraints and budget_policy objects get no narrative treatment beyond what the schema provides.

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 (decide/evaluate) and resource (a registry capability) with the decision framing made explicit: 'whether a registry capability is worth buying for your task'. It also scopes the evidence source ('from registry-run benchmarks only'). It does not, however, differentiate itself from close siblings like compare_capabilities or estimate_roi, which an agent must choose between.

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

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

Usage is implied rather than stated: the 'worth buying for your task' framing implies a pre-purchase decision, and 'from registry-run benchmarks only' implicitly excludes other evidence. There is no explicit when-to-use vs when-to-use-an-alternative guidance despite four sibling tools covering adjacent decisions (compare_capabilities, estimate_roi, get_quote).

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?

Annotations already declare the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the safety burden is covered. The description does add genuine content-level context beyond annotations by disclosing that results are trust-labelled — registry-run vs. PUBLISHER CLAIMED — and include signed attestations. It still omits anything about freshness, caching, or what happens when a capability has no benchmark data.

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 dense sentence with no filler, and the most important information (what evidence is returned) is front-loaded. It is telegraphic to the point of being slightly clipped, but nothing is wasted.

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 exists, so the description must carry the return-shape burden, and it does give a usable inventory of returned content types. However, for a tool in a crowded read-only evidence family it lacks guidance on selection versus siblings and on behavior when evidence is absent.

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 schema itself documents the accepted id/URI/slug forms for the single capability parameter. The description adds no format, resolution, or error semantics beyond the schema, so the 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?

States a specific verb (get) and resource (benchmark evidence) and enumerates the actual content returned: registry-run benchmark summaries, publisher claims, and signed attestations. This is far from tautological, but it never distinguishes itself from closely related siblings like get_provenance, get_capability, or evaluate_capability.

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?

There is no when-to-use guidance, no conditions or prerequisites, and no mention of any alternative tool. With nine siblings in the family (get_capability, get_provenance, evaluate_capability, compare_capabilities), an agent gets no help deciding which evidence-retrieval tool to call.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's remaining burden is return behavior — and with no output schema it delivers by enumerating the card's sections, including trust checks and the ak.offer.v1 offer. It does not cover failure modes (e.g., unknown id or slug resolution behavior), which keeps it from a 5.

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 dense sentence that front-loads the returned resource and then lists contents; every clause carries information. The long enumeration makes it slightly list-like rather than scannable, but there is no filler.

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

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

With no output schema, the description usefully substitutes by naming the card's contents, and annotations carry the safety profile while the schema fully documents the one parameter. The notable gap is the absence of any guidance on when this tool is the right choice versus evaluate_capability, get_quote, or compare_capabilities.

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 is a single required parameter ('capability') whose accepted formats (ak:publisher:name, versioned form, ak:// URI, slug) are fully documented in the schema at 100% coverage. The description adds nothing beyond that, so the 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 states a specific resource (the capability card) and enumerates its contents — purpose, permissions, price, evidence summary, trust checks, links, ak.offer.v1 offer. That is far more concrete than a tautology, but it never distinguishes this tool from siblings like evaluate_capability or compare_capabilities, which also operate on capability entities.

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?

There is no when-to-use or when-not-to-use guidance for the tool itself. The phrase 'use-when and do-not-use-when conditions' refers to fields inside the returned card, not to selecting this tool over its siblings, so an agent gets no routing signal.

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?

Annotations declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that the response contains hashes, attestations, and a transparency-log proof, which implies a verification-oriented read, but it omits whether the artifact must exist, whether proofs can be absent, or how freshness is handled.

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 no filler. It is front-loaded, though it front-loads outputs rather than purpose, which weakens its structural usefulness.

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-arg read tool with emphasized safety annotations, the description is thin but not misleading. It never says what the tool does with the capability ID or what a caller should expect when no provenance exists, leaving a real 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 coverage is 100% and the single parameter is fully documented with format examples in the schema. The description adds no parameter semantics at all, so 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 lists artifacts (hash, manifest, attestations, proof) but never states what the tool does. It reads as a return-value inventory rather than a verb+resource statement. A reader cannot tell whether it fetches, computes, or verifies provenance without guessing.

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?

There is no when-to-use guidance, no mention of prerequisites, and no differentiation from siblings like get_capability or evaluate_capability. The agent is left to infer whether this is a trust/verification lookup or a metadata fetch.

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?

Annotations declare readOnly and non-destructive, and the description adds critical context beyond them: the quote is time-limited (15 minutes), it performs no charge, and a purchase requires operator approval in the hosted checkout. This unauthored safety/expiry detail is exactly the value annotations cannot carry.

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 compact sentences with zero waste; the artifact and its constraints are front-loaded before the disambiguating no-charge note.

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 the artifact, expiry, no-charge behavior, and approval flow for a two-param read-only tool with full schema coverage and no output schema. Only minor gap is the absence of explicit sibling routing guidance.

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

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

Schema description coverage is 100%, so the schema already documents both capability and evaluation_id formats. The description adds no syntax or format detail beyond noting the checkout link, so 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?

States a specific artifact (signed 15-minute price quote) plus the deliverable (hosted checkout link), distinct from siblings like get_capability or evaluate_capability. An agent knows exactly what this returns.

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?

Implied usage via the evaluation_id param ('if you evaluated first'), suggesting the evaluate_capability → get_quote flow, but no explicit when-to-use/when-not statements or named alternatives among the nine 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?

Adds meaningful context beyond the annotations: reports are stored as AGENT REPORTED and explicitly do not affect evidence labels, trust, or ranking, plus a privacy note that no task text is retained. The non-idempotent, non-readonly write profile from annotations is neither contradicted nor contradicted-dependent, but the trust/ranking disclaimer is genuinely useful 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?

Three compact sentences, front-loaded with the action, then the storage/trust disclaimer, then the input constraint. Nothing is padded, though the final sentence largely restates schema enforcement.

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 13-parameter tool with no output schema and low schema coverage, the description covers flags and privacy but leaves most optional telemetry parameters unexplained and does not mention that failure_reason pairs with success=false. Adequate for the core call, incomplete for correct use of the optional fields.

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 only 38%, so the description must carry more weight, yet it explains no parameter semantics. Fields such as cost_usd, tokens_in/out, latency_ms, tool_calls, baseline_cost_estimate_usd, used_capability, and success are undocumented in both the schema and the description; the 'only the listed fields are accepted' line merely restates additionalProperties=false.

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: reporting how a capability performed. The name 'report_outcome' plus 'Report how a capability worked for you' makes the action unambiguous, and the surrounding siblings (evaluate_capability, unlock_capability) are distinguishable as different phases of the capability lifecycle.

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

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

Usage context is implied (report after using a capability) and the description clarifies the consequence of reporting, but it never states when to use this versus evaluate_capability or what preconditions apply. No explicit exclusions or alternative routing 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: ranking is 'by relevance only, never by payment,' and the matching is lexical rather than semantic — both materially shape expectations about result ordering and recall.

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 searchable-scope clause is front-loaded before the ranking caveat. Every clause carries information the agent cannot get from the schema or annotations.

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 search tool with no output schema, the definition is workable but thin: it omits any handling of limit, pagination, or what the result set contains. The rule relaxing return-value explanation only applies when an output schema exists, so the absence here leaves a small but real 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 coverage is 50%: query is documented ('at most 500 characters') while limit has no description at all despite being capped at 50. The description compensates partially by enumerating which fields the query is matched against, which clarifies what query strings should target, but it says nothing about the limit parameter.

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

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

States a specific verb and resource ('Lexical search over capability names, summaries, tasks and use-when conditions'), and the field list makes the search scope concrete. It does not name or differentiate against siblings such as get_capability or compare_capabilities, so an agent must infer this is the keyword-search entry point rather than a lookup or comparison.

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

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

No when-to-use guidance is given: nothing says to use this for discovery versus get_capability for a known ID, or when to prefer compare_capabilities. There are no exclusions, prerequisites, or escalation paths to 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?

Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds materially new traits: the download link expires in at most 15 minutes, repeating never charges, and key handling is governed by a privacy policy URL. This is real behavior beyond the structured hints, though the redundant 'repeating is safe' overlaps idempotentHint.

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 core action, which is good, but the middle sentence 'How the key is handled: the privacy page at /legal/privacy/' is a fragment that names a topic without explaining it and could be dropped or rewritten. Two of three sentences earn their place; one does not.

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

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

With no output schema, the description usefully describes the return ('a signed entitlement and a download link'), its time limit, and the approval prerequisite. For a mutation tool it covers the essentials, though it says nothing about failure modes (invalid/expired key) or the operator-approval workflow 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?

Schema description coverage is 100%, so the schema already documents all four parameters including the quote_id linking behavior and evaluation_id pattern. The description only restates that the license key comes from checkout, adding no syntax or format meaning beyond the schema. 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?

States a specific verb and resource ('Exchange the license key ... for a signed entitlement and a download link') and pins the scope ('from the checkout'). This is clearly distinguishable from siblings such as get_capability or evaluate_capability, which retrieve/inspect rather than unlock.

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?

Gives clear context for when this applies: after a purchase (which requires operator approval), and it references the evaluation path via evaluation_id in the schema. It stops short of naming explicit exclusions or a named alternative tool, so it lands at 4 rather than 5.

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