Record research evidence

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

Annotations set destructiveHint: false and readOnlyHint: false, making the mutating nature unclear from annotations alone. The description clarifies it creates a copy in the case (writing), and adds behavior like 'the server generates the stored filename' and returns a SHA-256 receipt. These go beyond annotations to inform the agent about side effects and output expectations. No contradictions found.

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 delivers the primary action and result, the second adds a key behavioral note. Every sentence is essential; there is no extraneous text. It is front-loaded with the most critical information for tool selection.

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 has 5 parameters, 4 required, no nested objects, and an output schema (implied by 'return a SHA-256 receipt'), the description is mostly complete for the core action. However, it lacks detail on what 'authorized case' means, prerequisites like configured import root, and the significance of the method enum. The output schema presence reduces the need to explain return values, but the description could be more thorough about constraints or failure 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 0%, so the description must compensate for all 5 parameters. It explains the purpose of path (source file) and case_id (destination case), hints at method's role via the sibling context (research methods), and mentions note but not media_type. For a critical param like media_type, the description provides no guidance. However, the schema's enums for method help, and overall the description adds meaning for most core parameters.

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 specific verbs and resources: 'Copy one bounded file from a configured import root into an authorized case and return a SHA-256 receipt.' This clearly distinguishes the tool from sibling tools like research_import_sarif or research_record_patch_verification, as it describes a specific import-into-case action with a unique outcome (SHA-256 receipt).

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 tool is for importing a single bounded file, which distinguishes it from bulk imports or other research actions. However, it does not explicitly state when not to use it (e.g., if the file is not bounded or the import root is not configured) or reference any alternative tools among the siblings for different file types or use cases. The guidance is adequate but minimal.

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