refang_iocsRestore defanged URLs, domains, IP addresses, and emails to their live forms for security analysis; handle the output with care and do not click or browse the indicators.
Reverse defanging (hxxp -> http, [.] -> ., [@] -> @). The result contains LIVE indicators: handle with care and do not click or browse to them.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text containing URLs, IPv4 addresses, emails or domains, max 64 KB |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds the critical non-obvious trait: the output contains live indicators and must not be interacted with. This is exactly the kind of safety context annotations cannot convey.
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, front-loaded with the transformation and followed by the essential safety warning. Nothing is wasted.
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 transformation tool with no output schema, the description covers purpose, accepted inputs via schema, and the key property of the returned data. It does not explicitly state the return type or shape, though the warning implies the result contains live text.
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?
There is one parameter with 100% schema description coverage, and the schema already explains the accepted content and 64 KB limit. The description adds no parameter detail, which is acceptable given the baseline for fully documented 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 transformation ('Reverse defanging') and illustrates it with concrete mappings (hxxp -> http, [.] -> ., [@] -> @). It clearly distinguishes the operation from its sibling defang_iocs by specifying it is the reverse.
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 use case is clear: undo defanging on indicators. It adds an explicit operational caution ('do not click or browse'), but it does not name defang_iocs as the inverse alternative or describe when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.