Restore quarantined email security events by providing event IDs, returning task IDs to track operation progress.
Restore one or more previously quarantined events by event ID. Returns task IDs to track progress.
| Name | Required | Description | Default |
|---|---|---|---|
| eventIds | Yes | List of event IDs to restore |
Changes observed during successful MCP inspections.
v2.2.2v2.2.1v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It discloses that the operation returns task IDs for progress tracking, which is useful asynchronous behavior context. However, it does not mention whether the restoration is reversible, if it requires special permissions, what happens if an event ID is already restored, or any rate limits.
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, each earning its place: first states the action and input, second states the return value. No wasted words, perfectly front-loaded.
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 has only one parameter with 100% schema coverage, no output schema, and no annotations. The description covers the core action and return value, which is near-complete for a simple restore operation. It could mention potential errors or prerequisites (e.g., events must be quarantined), but over half a dozen sibling tools exist, and this is well-defined enough for an agent to invoke correctly.
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 baseline is 3. The description adds value by confirming that eventIds are quarantined event IDs (tying to the resource), and that multiple can be restored at once. It also clarifies the output provides task IDs, helping the agent understand the param's role and expected outcome.
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 verb 'Restore' and the resource 'quarantined events by event ID', which distinguishes this tool from siblings like hec_restore_emails (which likely works on email IDs) and hec_quarantine_events (the inverse operation). It also mentions returning task IDs for tracking, adding useful outcome details.
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 this tool is used after an event has been quarantined, and mentions tracking via task IDs, but does not explicitly state when to use this versus hec_restore_emails or how to follow up on task status (e.g., use hec_get_task_status). No alternative or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.