Audifact

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

With no annotations, the description carries the behavioral burden alone, and 'public' is a genuine disclosure that this data requires no authentication or permission. However, it says nothing about rate limits, whether the proof is immutable, or what an invalid/unknown hash produces. Some value added, but incomplete for a no-annotation tool.

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

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

One front-loaded sentence with zero wasted words; the key constraint (64-char hex event_hash) lands immediately.

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

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

For a single-parameter read tool this is close to sufficient, but with no output schema the description gives no hint of what 'proof data' contains, and there is no failure-mode guidance. Adequate minimum, with clear 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 coverage is 100% and the single parameter's description repeats the format constraint ('64-character hex event hash') already present in the schema. Baseline 3 applies since the schema does the work and the description adds no new syntax or semantics.

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

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

States a specific verb ('Fetch') and resource ('public proof data') scoped to an event_hash, which is enough for an agent to distinguish this read tool from the logging siblings (log_decision, log_outcome, list_my_recent_decisions). It stops short of explicitly naming a sibling or contrast, so it is clear but not fully differentiated.

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 context, no prerequisites, and no mention of the sibling tools that might be alternatives. The agent is left to infer that this is the retrieval companion to log_decision/log_outcome purely from the name.

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

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

With no annotations, the description carries the full burden, and it discloses only one real behavioral trait: results are scoped to the API key's org. It says nothing about ordering/recency semantics, pagination direction, default limits, permissions, or what a returned event contains.

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

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

A single front-loaded sentence with no filler or repetition of the name. It is efficient, though it stops short of earning a top score by omitting any operational 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 three-parameter list tool with no output schema and no annotations, the description is minimally viable but leaves the agent guessing about ordering ('recent' is undefined), default page size, and the shape of a decision event.

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 67%: limit and cursor are self-documented, while agent_public_key has no schema description and the description supplies its meaning ('for a specific agent public key'). That closes the gap but adds no syntax, format, or pagination guidance 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?

States a specific verb (List) and resource (recent decision events) with scope qualifiers (specific agent public key, API key org). This distinguishes it from write-oriented siblings like log_decision and log_outcome, 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?

No statement of when to use this tool versus get_proof, log_decision, or log_outcome, and no prerequisites or exclusions. Usage is only implied by the name and the 'list' verb.

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

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

With no annotations, the description carries the full burden and does substantial work: events are immutable once recorded, organization is derived from the API key, managed mode provides strong auditability, and the scenario hash is computed server-side. It omits failure modes, rate limits, and what a successful response returns.

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 action, then dense but substantive sentences covering modes, immutability, org derivation, and hashing. Every clause carries information, though the run-on sentences would read better as bullets.

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 20-parameter, zero-required, nested-object tool with no output schema, the description covers the hard parts: signing modes, key management, org scoping, scenario resolution, immutability, and outcome linkage. It leaves the decision_type/label/value semantics and response shape to the schema and inference.

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 75%, and the description resolves the genuinely ambiguous parameters: the managed-vs-client signing path (agent_name vs agent_private_key_b64/signature/public key), why scenario_hash is normally omitted, and the organization_id exclusion. It adds little for the many public_* mirror fields and decision_label/value, which rely on the schema alone.

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: 'Log a signed decision event to the ledger.' It immediately distinguishes itself from the outcome-recording sibling by scoping to the decision event and noting that linked outcomes must match the decision's signing method.

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 operating guidance: managed mode is the default, omit signing fields and pass agent_name; client-side signing is for maximum provenance; don't send organization_id; usually omit scenario_hash. It stops short of explicitly routing the agent between log_decision and siblings like log_outcome or list_my_recent_decisions.

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

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

With no annotations, the description carries the full burden and largely succeeds: it discloses that the managed key is auto-resolved from the linked decision's agent, that signing method must match the source decision, that agent_name is ignored, and that scenario fields are rejected because context is inherited. It omits immutability/error behavior expected of a signed ledger event, so it isn't complete.

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?

Four tight sentences in a single paragraph, front-loaded with 'what it does' before the signing branch detail. Slightly dense with two clauses covering key/signature alternatives, but every sentence earns its place.

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

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

For a 14-parameter, unannotated, no-output-schema tool, the description covers signing, linkage, and scenario inheritance but leaves the public_* mirroring fields, ts semantics, idempotency, and failure modes unaddressed. Adequate to call the tool, incomplete for the tool's complexity.

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%, and the description meaningfully supplements it by explaining the signing parameters as two mutually exclusive modes, the decision_event_hash linkage, and why agent_name/scenario fields are non-operative here. It does add real meaning beyond the property-level descriptions, though ts, metadata_json, and the public_* mirroring rules are left to 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 and resource ('Log a signed outcome event') and its linkage requirement ('linked to a prior decision via decision_event_hash'), which is enough to separate it from log_decision. It never names a sibling explicitly, so the differentiation is inferential 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?

Gives concrete operating guidance: omit signing fields in Managed Mode (default), pass agent_private_key_b64 or agent_public_key + signature for client-signed decisions, and the signing method must match the linked decision. It doesn't state when to prefer this tool over log_decision, but the signing-mode branches are genuinely actionable.

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 behavioral burden and does well: it discloses idempotency keyed on public_key and that the operation is scoped to the API key's organization. It stops short of describing failure modes (e.g., malformed key, conflicting name) or what a lookup returns versus a fresh registration.

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, zero filler, with the primary action front-loaded and the idempotency constraint immediately after. Nothing to trim.

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 tool with no output schema and no annotations, the description covers identity, scope, and idempotency but omits the return contract—crucial given the tool can either create or fetch an agent and callers cannot tell which branch executed or what identifiers come back.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema. The description adds that public_key functions as the idempotency key, which is meaningful beyond the schema's 'Base64 Ed25519 public key', but 'name' receives no additional interpretation. Baseline 3 with a slight lift.

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 set (register/look up) and resource (agent identity) plus the organizational scope ('under the API key's organization'). The siblings (get_proof, log_decision, log_outcome, list_my_recent_decisions) are clearly distinct operations, so an agent can differentiate without opening any schema.

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 dual verb 'register or look up' implies two usage contexts and the idempotency note hints that repeated calls are safe, but the description never states explicitly when to choose registration vs lookup or what prerequisites exist. Usage is inferable rather than stated.

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