Cronozen Proof

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

With no annotations, the description does useful work: it discloses O(n) sequential cost, whole-chain scope, and first-broken-index reporting on tampering. It omits read-only confirmation, error behavior for a missing domain or empty chain, and any return shape (no output schema exists), leaving meaningful gaps for a diagnostic 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 tight sentences, front-loaded with the action and scope, followed by the verification mechanism and failure behavior. No filler or repetition.

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

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

Given no annotations and no output schema, the description should say more about the result (what is returned when intact vs. broken) and error conditions. It covers the core execution model but leaves the agent without a full contract for a 4-parameter verification 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 description coverage is 100%, so the schema already documents domain, fromIndex, toIndex, and batchSize; baseline is 3. The description adds no constraint on how fromIndex/toIndex interact with 'entire chain' verification or what batchSize affects, so it does not exceed 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?

States a specific verb+resource: verifying a SHA-256 hash chain for a domain, including scope ('entire') and mechanism ('O(n) sequential verification of all DPUs'). It implies a distinction from the sibling proof_verify (full chain vs. presumably individual proof), but never names or explicitly contrasts with any sibling.

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?

Tamper-detection and whole-chain verification imply when to use it, but there is no explicit when/when-not guidance and no mention of proof_verify, proof_public_verify, or proof_get as alternatives for narrower checks. The agent must infer the routing.

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

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

With no annotations, the description carries the full burden. It usefully enumerates what the exported document contains (compliance status, 6W extraction, hash chain, policy snapshot), which is real behavioral context. But 'Exports' is ambiguous — it never says whether the result is returned inline, written to a file, or persisted, nor what permissions or side effects are involved.

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-loaded with the action and output format, then the payload contents. Dense but every clause contributes; only mild jargon load (DPU, 6W) that is partially self-explaining.

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, and the description does compensate by describing the exported document's contents. Missing is the delivery mechanism (inline string vs file) and error behavior for an invalid ID, but for a single-parameter export tool the coverage is solid.

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 one parameter and schema description coverage is 100%, so the schema already explains that 'id' is the DPU ID to export. The description adds no format, validation, or lookup-failure semantics 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?

States a specific verb and resource: 'Exports a Decision Proof Unit as a JSON-LD v2.0 proof document' with a named ontology (Cronozen Evidence Ontology). This is clearly distinct from siblings like proof_verify or proof_get, though it never names an alternative explicitly.

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

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

Usage is only implied: an agent can infer this is the tool for producing an interoperable JSON-LD artifact versus the raw lookups in proof_get. There is no statement of when to prefer it over proof_get or proof_report, and no 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, the description must carry the full behavioral burden. It discloses the broad return contents (hash chain position, AI involvement, human control, evidence level, compliance information), which helps, but omits permissions, not-found/error behavior, and whether the operation has any 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 front-loaded sentence with no filler. The list of included details is informative, though slightly long, and every clause contributes to understanding the returned data.

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 retrieval tool, the description gives a reasonable summary of the return payload even without an output schema. It still leaves gaps around error handling, access requirements, and exact response shape, which matters more because annotations are 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?

There is only one parameter, and the schema already documents it completely as 'The DPU ID to retrieve' with 100% coverage. The description adds no additional semantics such as ID format or validation rules, so the schema is doing the work.

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 verb and resource: 'Retrieves a Decision Proof Unit by ID'. This clearly distinguishes a lookup operation from verification or recording siblings, though it never explicitly names those 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?

Usage is implied: call this when you have a DPU ID and want full details. However, there is no explicit guidance on when to use this versus proof_verify, proof_chain_verify, or proof_report, nor any stated prerequisites.

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 and does well: it states that no credentials are required and that the operation checks hash validity and chain links, implying a read-only verification with a returned status. It does not explicitly state that the operation is non-destructive or describe the exact response shape, leaving some minor behavioral details unstated.

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 front-load the core operation and then add the key differentiator of no authentication. Every sentence contributes relevant information with no 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?

For a simple one-parameter public verification tool without an output schema, the description covers what is checked and that verification status is returned. It could briefly clarify how this differs from the authenticated proof_verify sibling, but it is otherwise complete enough for correct invocation.

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

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

Schema description coverage is 100%, and the single parameter is fully documented in the schema. The description adds only that the DPU is being publicly verified, which is consistent but largely redundant with the schema, so the baseline of 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 verb and resource — publicly verifies a DPU's cryptographic integrity — and lists the concrete checks performed (SHA-256 validity and chain link integrity). The word "publicly" distinguishes it from authenticated sibling tools such as proof_verify.

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

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

The description clearly establishes the usage context: public verification requiring no credentials, implying it should be used when authentication is unavailable or undesirable. It does not explicitly name proof_verify as the alternative for authenticated verification, but the public/no-auth framing provides a strong selection 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?

With no annotations, the description carries the full burden. It does disclose that this is a create operation producing a chained SHA-256 record and describes the return payload (decision_id and chain hash), but says nothing about immutability, idempotency, permission requirements, or what happens on failure.

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 tight sentences: purpose, mechanism, and return value, with the core action front-loaded. No filler, though the final sentence partly restates the first.

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 10-parameter mutation tool with no annotations and no output schema, the description covers what it creates and roughly what it returns. It is missing the behavioral details an agent would need to call it safely, such as whether records are append-only, whether duplicate submissions are rejected, and any auth requirements.

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 fully documents all 10 parameters including the evidence_level enum and defaults. The description adds no parameter-level guidance beyond the schema, which is acceptable given that baseline.

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: 'Records an AI execution as a Decision Proof Unit (DPU)', naming the artifact and its cryptographic hash-chain nature. It is implicitly distinguishable from the verify/get/export siblings, but that differentiation is left for the agent to infer rather than stated.

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 indication of when this tool should be used versus the siblings (proof_verify, proof_get, proof_chain_verify), and no prerequisites such as whether a prior decision step is required. The phrase 'records an AI execution' loosely implies post-decision logging, but nothing explicit is offered.

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 full disclosure burden. It does describe the return contents (formatted document, hash chain verification, PDF/JSON-LD links), which is valuable given there is no output schema, but it does not state whether the report is persisted, whether generation has side effects, or any auth/permission 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?

Two tight sentences, front-loaded with what the tool produces, followed by the usage cue. 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?

With one simple parameter and no output schema, the description adequately explains what is returned (document contents and download formats) and when to call it. Minor gap is the lack of clarification versus proof_export_jsonld and any side-effect/persistence notes.

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

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

Schema description coverage is 100% and the single 'id' parameter is documented as 'The DPU ID to generate a report for'; the description's 'for a DPU' merely echoes this. Baseline 3 applies since the schema already does the work.

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?

A specific verb and resource: 'Generates a structured decision report for a DPU', with contents enumerated (decision details, hash chain verification, download links). It distinguishes itself from proof_get by being report/document output, though it doesn't explicitly clarify its boundary against the sibling proof_export_jsonld despite mentioning JSON-LD.

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?

'Use this after proof_record to provide a downloadable evidence report' gives clear sequencing and intent for the tool. It lacks explicit exclusions or a comparison to alternatives like proof_export_jsonld when only one format is wanted.

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 what is checked (hash consistency) and that a verification status is returned, but says nothing about authentication needs, what happens when the optional data is omitted, or failure/error behavior for an invalid or missing proof.

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 the core action front-loaded and no filler. Slightly terse given the verification semantics that go unexplained.

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, yet the description does not characterize the returned verification status (possible values, whether details accompany it), and with a nested object parameter and zero annotations, an agent still lacks enough to predict behavior in edge cases.

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 schema itself documents proofId and the optional 'data' object for re-verification, so the description need not repeat them. Baseline 3 applies; it adds no meaning beyond the schema for either 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 (verifies) and resource (a specific proof record) plus the mechanism (hash consistency check, verification status). It does not differentiate from siblings like proof_public_verify or proof_chain_verify, which an agent must infer from names alone.

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 'a specific proof record' hints this is the by-ID counterpart to chain or public verification, but there is no explicit when-to-use guidance, no mention of prerequisites, and no named alternative among the six proof_* siblings.

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