evidence_create_sealed

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

With no annotations, the description carries the full burden and delivers. It discloses the polling until CLOSED, the async Task for MCP clients vs synchronous result for others, the requirement for caseFileId, the file input contract variants, and the return shape (group id, CLOSED status, evidence ids + sha256). This goes well beyond basic expectations.

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 dense but every sentence earns its place. It opens with the primary purpose and flow, then gives key behaviors, requirements, and alternative use cases. No filler words or redundancy.

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 complex with nested file contracts and multiple parameters, but the description covers prerequisites, use modes, async behavior, return values, and when to choose alternatives. Since there is no output schema, explaining the return fields is essential and done well.

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?

Despite 100% schema coverage, the description adds semantic value: it explains the shared FileInput contract (local path, base64, HTTPS URL, n8n binary item) and clarifies parameter interplay (evidenceGroupId to add to existing OPEN group, groupName/groupType only used when creating a new group). This helps the agent construct valid calls.

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 full action: creates/reuses an evidence group, registers and uploads files, then seals it. It explicitly distinguishes itself from the atomic sibling tools (evidence_group_create, evidence_group_evidence_register, evidence_group_close) by framing it as the 'full flagship evidence flow in one call.'

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 explicit when-to-use guidance: use the atomic tools when you need to inspect/react to intermediate steps, and this tool for the full flow. It also states the prerequisite (case_file_create -> caseFileId), the ability to add to an existing OPEN group, and explains the asynchronous vs synchronous behavior for different client types.

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