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

With no annotations, the description carries the full behavioral burden, and it says nothing beyond the act of creation: no persistence guarantees, no required auth/permission level, no indication of whether the case is immediately visible to get_case/list_cases, and no side effects. For a mutation tool this is a meaningful gap.

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 short sentence with the verb-resource pair front-loaded and zero filler. It is efficient, though its brevity is partly under-specification rather than disciplined conciseness.

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?

An output schema exists, so return values need not be explained, and the schema fully covers the two simple parameters. However, as an unannotated mutation tool it omits permissions, side effects, and any post-creation workflow hints, leaving the definition minimally but not fully adequate.

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 already documents both 'name' and 'description' including an example and a default. The description adds no parameter meaning beyond the schema, so 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?

States a specific verb and resource ('Create a ... case') and the domain ('forensic investigation'), which is enough to distinguish it from the read-oriented siblings (list_cases, get_case, verify_evidence). It does not explicitly name or contrast the nearest alternative, so it stops short of a 5.

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 guidance on when to create a case versus reusing an existing one, no prerequisites (e.g., authentication or permissions), and no mention of sibling tools such as register_evidence that would follow. The agent must infer context entirely.

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 behavioral burden. 'Get' weakly implies a read, but the description never states that this is a non-mutating lookup, what permissions are required, or whether case data is sensitive/auditable. With zero annotation coverage this is a notable gap.

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 short sentence with no waste, front-loaded with the verb and resource. Appropriate size for a one-parameter lookup tool.

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?

Output schema exists so return values need not be described, and the single parameter is fully documented in the schema. But with no annotations and no usage guidance, an agent still lacks context on safety profile and when to prefer this over list_cases/get_evidence. Minimum viable.

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 case_id description already provides format examples (CASE-2026-001, internal UUID). The description adds nothing about the parameter, so the baseline of 3 applies – the schema does the heavy lifting.

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 ('details of a specific forensic case'), clear enough to distinguish from siblings like list_cases (plural, listing) and create_case (mutation). However it doesn't explicitly contrast with get_evidence or explain what 'details' includes, leaving some ambiguity about sibling selection.

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, no prerequisites, no mention of alternatives. The singular 'a specific forensic case' weakly implies you need a known case_id, but nothing tells the agent when to reach for this versus list_cases or get_evidence.

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 behavioral burden but only implies a read via 'Get'. It says nothing about whether the evidence must exist, error behavior for unknown IDs, any access restrictions, or what happens with the two accepted ID formats. Minimal disclosure for a tool with zero annotation coverage.

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 wasted words and the verb/resource established immediately. It is efficient, though almost too terse to carry any extra value.

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

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

An output schema exists, so return values needn't be explained, and there is only one well-documented parameter. The definition is adequate for a simple lookup but omits error/edge behavior and sibling differentiation that would make it fully complete.

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

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

Schema description coverage is 100%, and the single parameter is documented with concrete examples ("EVD-001" or internal UUID). The description adds no additional meaning beyond 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?

States a specific verb ('Get') and resource ('a specific evidence item'), which is clear and unambiguous. However, it does nothing to distinguish itself from siblings like get_case or list_evidence/verify_evidence, leaving the agent to infer from the name 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?

There is no guidance on when to use this tool versus list_evidence, verify_evidence, or register_evidence. The description offers no context, prerequisites, or exclusions, so an agent must guess that this is the single-item lookup counterpart to list_evidence.

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 does add real behavioral context: the ordering (newest first) and the fields returned. However, it is silent on whether the full result set is returned unbounded, whether pagination or limits exist, and whether any permissions are required.

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 short sentences, front-loaded with the purpose. The second sentence largely restates the output schema's fields, which is mild redundancy but not enough to hurt readability or comprehension.

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?

An output schema exists, so return values need not be explained in prose, and the empty input schema means there are no parameter gaps to cover. The only missing piece is whether results are bounded or paginated, which is a minor gap for a zero-parameter list tool.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond confirming the operation takes no input.

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 ('List all forensic cases') and the scope ('all') implicitly distinguishes it from get_case, which retrieves a single case. It is unambiguous but never explicitly contrasts itself with the sibling read tools.

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 guidance on when to call this versus get_case, and no mention of whether the result set is filtered, paginated, or capped. The agent must infer that 'all' means no filtering and no pagination control exists given the empty parameter schema.

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 behavioral burden. It doesn't state whether this is a read-only operation, whether it paginates, what the return volume might be, or any auth requirements. For a list tool with no annotations, this is a significant gap.

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 single sentence is concise and front-loaded, but it's so terse that it sacrifices useful context. It earns points for zero waste, but doesn't provide enough substance to be considered well-structured for a list tool.

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?

An output schema exists, so return values needn't be explained. The single optional parameter is fully documented in the schema. However, with no annotations and no behavioral context, the description is barely adequate for an agent to understand when and how to use this tool versus siblings like get_evidence or list_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 description coverage is 100% — the case_id parameter is fully documented in the schema including its optional nature, accepted formats (case number or UUID), and default behavior. The description adds no parameter information beyond what's already in the schema, so 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?

States a clear verb+resource: listing registered evidence items. This distinguishes it from get_evidence (singular retrieval) and register_evidence (creation). However, it doesn't explicitly contrast with list_cases, the closest sibling, leaving some sibling differentiation implicit.

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 (you call it to see a list of evidence), but provides no explicit when-to-use guidance, no exclusions, and doesn't name alternatives like get_evidence for single-item retrieval. The optional case_id parameter's behavior is documented in the schema, not the description.

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 behavioral burden and discloses important side effects: it computes a SHA-256 hash, stores metadata, and explicitly states the original file is never modified or copied. It still omits permissions, duplicate-registration behavior, and error conditions, but the core mutation and file-safety behavior are clearly conveyed.

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 short sentences with the purpose front-loaded, followed by concise behavioral details. Every sentence adds useful information without repetition or 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?

Given no annotations, complete parameter descriptions, and an existing output schema, the description covers the essential action and key side effects. It is nearly complete, though it could mention prerequisites such as whether the case must already exist or what happens on duplicate registration.

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 three parameters, including case_id format, path, and evidence_type enum values. The description adds no parameter-level meaning beyond what the schema provides, which matches the baseline of 3 for fully covered schemas.

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 ('Register') and resource ('a new piece of evidence in a forensic case'), making the action immediately identifiable. It distinguishes itself from sibling tools like get_evidence, list_evidence, and verify_evidence by focusing on registration of new evidence rather than retrieval or 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 gives no explicit when-to-use guidance, prerequisites, or alternative tools. It implies registration is for adding new evidence, but does not say when to prefer it over verify_evidence or how to handle existing evidence, leaving usage conditions entirely to inference.

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 the core behavior (recompute hash, compare to the value stored at registration) and implies a non-destructive read, but never states permissions, whether the result is persisted or logged, or what happens on a mismatch.

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 short sentences with the mechanism front-loaded and no filler. The phrase "critical forensic operation" is mildly editorial but harmless, so structure is strong though not perfect.

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?

An output schema exists, so the return shape need not be explained, and the one parameter is fully covered. The description is sufficient to call the tool, though it leaves the mismatch behavior and read/write semantics implicit.

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 evidence_id parameter is already fully documented in the schema (evidence number or UUID). The prose adds no parameter-level detail, 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 gives a specific verb+resource (verify evidence) and even names the mechanism (re-computing its SHA-256 hash) plus the goal (detect tampering). This clearly distinguishes it from the read-only siblings get_evidence and list_evidence, which retrieve rather than validate.

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?

It implies usage ("critical forensic operation to detect evidence tampering"), which tells an agent the context in which it matters. However, it names no alternatives or preconditions, e.g. whether get_evidence must be called first or when verification is unnecessary.

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