Kevros — Agentic Identity Trust

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

Annotations are all false, so the description carries the behavioral disclosure burden. It reveals that each attestation extends an "append-only evidence chain" (implying irreversibility) and states the cost per call, both of which add value beyond the annotations. It does not detail authorization or rate limits, but the append-only nature is a key constraint that is disclosed.

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

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

The description is two sentences plus a cost clause, with no filler. The purpose, key behavioral trait (append-only), verifiability, and cost are all front-loaded and 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?

The description, combined with the full schema coverage and presence of an output schema, covers the essential aspects: purpose, behavior (append-only), cost, and parameters. It lacks explicit warnings about prerequisites or failure modes, but the append-only nature is key and stated. Slightly more context about relationship to verification tools would help, but the tool is self-contained for its simple function.

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

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

The input schema provides complete descriptions for all 4 parameters (100% coverage), so a baseline of 3 applies. The description adds no parameter-specific detail beyond implying that `action_description` and `action_payload` capture the action taken, which is already evident from the schema.

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

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

The description clearly states "Create a hash-chained provenance record for an action you've taken," identifying the specific verb (create) and resource (provenance record). It distinguishes from sibling verification tools like `verify` and `check-peer` by emphasizing record creation and chain extension.

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 phrase "for an action you've taken" sets a clear context for when to use the tool. However, it does not explicitly exclude verification or other sibling tools, nor does it mention alternatives. This is clear context without 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?

Annotations only say readOnlyHint=false, destructiveHint=false, etc., which are uninformative. The description adds valuable behavioral context: 'Proves that the command was issued in service of the declared intent' and states a cost of '$0.02 per call.' These go beyond the basic hints and give the agent a sense of side effects and billing.

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 concise sentences: core function, proof guarantee, and workflow/cost. Every sentence earns its place, is front-loaded with the primary action, and has no fluff or repetition.

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

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

For a 7-parameter tool with an output schema, the description covers the essential lifecycle (bind then verify-outcome), explains the cryptographic purpose, and notes cost. It does not discuss parameter behavior or output format, but those are handled by the schema, making it adequately complete for an agent.

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?

Input schema coverage is 100%, so the schema already documents all 7 parameters. The description adds no specific parameter-level guidance beyond the general intent/command concept. Baseline 3 applies since the description does not need to repeat schema details.

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

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

The description clearly states the tool's purpose: 'Declare an intent and cryptographically bind it to a command.' It uses a specific verb ('bind') and resource ('intent to command'), and distinguishes itself from sibling verification tools by emphasizing the cryptographic proof and by pointing to verify-outcome as the follow-up 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 gives an explicit usage hint: 'Use verify-outcome after execution to close the loop.' This indicates a sequential workflow. However, it does not explicitly contrast with alternatives like attest, verify, or bundle, so it misses the full 'when/when-not' 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?

Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable context beyond annotations: the bundle's contents (hash-chained provenance, intent bindings, PQC attestations), the key property of independent verifiability without Kevros access, and the per-call cost of $0.05. This is significant extra behavioral and operational info.

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 four short, front-loaded sentences. Each sentence adds unique information: what is generated, what it contains, a key property (independently verifiable), and cost. There is no fluff or repetition; it is concise and well-structured.

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 there is an output schema and well-documented parameters, the description does not need to explain return values or parameter details. It covers the core purpose, contents, verifiability context, and cost, making the tool complete for an agent to decide when to invoke it. The complexity is moderate, but the description plus schema/annotations fully cover the needed 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?

Schema coverage is 100% with detailed descriptions for all 7 parameters, so the schema already carries the parameter meaning. The description does not add extra syntax, formatting, or parameter-specific guidance beyond what is in the schema; it only references the contents generally, which maps to the boolean includes. Hence 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 uses a specific verb+resource ('Generate a certifier-grade compliance evidence bundle') and clearly distinguishes from sibling verify/attest tools by emphasizing bundle generation and independent verifiability. It also lists key components (hash-chained provenance, intent bindings, PQC attestations), making the purpose unmistakable.

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: this tool produces a compliance bundle for certifier-grade evidence, independently verifiable without Kevros access, at a known cost. It implies usage when an external verifiable bundle is needed, but does not explicitly mention alternatives or when not to use it relative to siblings like verify or attest.

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 it is a safe read operation. The description adds value by noting the tool is free, requires no API key, and specifying the exact return fields, which are not covered by annotations.

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, information-dense sentence that front-loads the primary action and then lists the return values. There is no fluff or redundancy; every part 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?

Given the tool's simplicity (one parameter), the rich annotations, the existence of an output schema, and the description's inclusion of cost/auth behavior and return fields, the description is fully sufficient for an agent to select and invoke 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?

The schema provides 100% documentation coverage for the single parameter, with a clear description ('ID of the peer agent to look up'). The tool description does not add further param details, but this is unnecessary given the schema's completeness.

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

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

The description clearly states the tool's function with a specific verb ('Check') and resource ('another agent's trust score and governance history'), and enumerates the return fields. It distinguishes itself from siblings like verify and status by focusing on peer trust assessment.

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 a peer's trust, but does not explicitly state when to use it over sibling tools. There is no mention of alternatives or exclusions, though the specificity of the purpose makes the intended context reasonably 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds 'Free' as a behavioral trait (no cost) and clarifies the target scope, but does not provide deeper details like response structure or side effects beyond what annotations offer.

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: two short sentences. Every word earns its place, with 'Free' conveying a useful behavioral note without unnecessary elaboration.

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 health-check tool with one optional parameter and an output schema, the description is reasonably complete. Annotations cover safety, the schema covers parameters, and the output schema covers return values. However, the lack of usage guidance and sibling differentiation prevents a perfect score.

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 single parameter 'verbose' is fully described in the schema with its default and purpose. The tool description does not add parameter-level meaning, but since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Check') and the resource ('governance gateway health status'), making the tool's purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'status' or 'check-peer', so it lacks explicit sibling distinction.

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

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

No guidance is provided on when to use this tool versus alternatives. The description mentions it is 'Free' but does not explain scenarios where a health check is preferred over other governance gateway tools, nor any 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context: 'Free' indicates no monetary cost, and listing 'billing status' implies the tool surfaces financial/account state. This goes beyond the annotation safety profile and gives the agent useful expectations about what the operation checks.

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, information-dense sentence. It front-loads the primary action ('Check your current usage and quota') and immediately follows with the specific data points. Every word earns its place; no fluff, no irrelevant 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?

The tool is simple (one optional boolean parameter) and has an output schema, so the description doesn't need to explain return values. It covers the essential scope (usage, quota, rate limits, billing), mentions cost ('Free'), and is entirely self-contained. The annotations and schema fill any remaining gaps, so no further context is needed.

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 covers 100% of the parameter description ('Include hash-chain integrity check and latest provenance epoch'). The tool description itself does not mention the parameter, but since the schema already provides a clear semantic explanation, the description adds no extra value here. Baseline of 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 starts with a specific verb 'Check' and clearly identifies the resource: 'your current usage and quota'. It enumerates the exact data points (calls used/remaining, tier, rate limits, billing status), making it unmistakably distinct from sibling tools like health or verify, which focus on system status or cryptographic 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?

The context is clear: use this tool to inspect usage and quota. It doesn't explicitly name alternatives or exclusions, but the description's specificity ('calls used, calls remaining, tier, rate limits, billing status') implicitly sets it apart from sibling tools. A 4 is appropriate because it lacks an explicit 'use instead when...' clause, but the intended usage is unambiguous.

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

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

The description adds significant behavioral details beyond annotations: it enumerates the three possible verdicts (ALLOW, CONSTRAIN, DENY), explains the legacy CLAMP alias, mentions the hash-chained provenance ledger recording each call, and states the cost per call. This complements the annotation hints effectively.

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, each carrying distinct, relevant information: purpose, return values, and operational details (ledger + cost). No redundancy or filler, and the most important 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?

Given the tool's moderate complexity (6 parameters, nested objects) and the presence of an output schema, the description covers the essential operational context: when to use it, what it returns, side effects, and cost. It does not delve into error conditions or rate limits, but this is not critical for an agent to invoke 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?

Input schema description coverage is 100%, so the description correctly relies on the schema for parameter details. While the tool description references 'policy bounds' which maps to policy_context/action_payload, it does not add specific parameter semantics beyond what the schema already 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?

The description clearly states the tool verifies an action against policy bounds before execution, using a specific verb and resource. It distinguishes from sibling tools like verify-outcome and verify-token by focusing on pre-execution policy 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?

The phrase 'before executing it' provides clear context for when to use this tool. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to understand its primary use case.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds the conceptual loop and mentions 'Free (included with bind)' but doesn't elaborate on side effects or comparison semantics. No contradiction with annotations.

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: the first clearly states the purpose, the second explains the workflow and cost. Minimal fluff, efficiently front-loaded.

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

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

The description outlines the tool's role in a workflow and mentions 'Free (included with bind)', but doesn't mention prerequisites like having a binding_id from governance_bind or how tolerance works. The output schema exists, so return values are presumably covered.

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 baseline is 3. The description does not add extra parameter meaning beyond the schema; it only contextually references 'actual_state' without providing new details.

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

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

The description clearly states the tool's specific purpose: 'Verify that an executed action achieved its declared intent.' It distinguishes itself from sibling tools like 'verify-token' by focusing on outcome verification and explicitly outlining the loop: 'intent -> command -> action -> outcome -> 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?

The description provides clear context for when to use the tool ('Closes the loop: intent -> command -> action -> outcome -> verification'), implying use after action execution. However, it does not explicitly exclude or compare against alternatives like 'verify' or 'verify-token'.

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 indicate read-only, idempotent, non-destructive. The description adds behavioral detail about what verification checks (authenticity, issuer, current authorization) and the lack of an API key requirement, enhancing transparency beyond the annotation flags.

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, purpose first, then verification scope, then cost/access. No redundant or 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?

With schema covering parameters, annotations covering safety, and output schema present, the description adequately covers purpose and usage context for correct invocation. The mention of 'after any halt or mode transition' adds important contextual 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 descriptions fully document both parameters, including the deprecation and ignored behavior of token_preimage. The tool description does not add further parameter-level detail, so the baseline 3 applies given high schema 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 verifies a release token from another agent, confirming authenticity, gateway issuance, and current authorization. This specific verb-resource combination distinguishes it from general tools like verify and verify-outcome.

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

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

Provides clear context on when to use: when a release token is received from another agent, especially after halt or mode transitions. It does not explicitly compare against sibling tools like verify or verify-outcome, so no exclusionary guidance.

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