Alienvault Otx

Lookup Indicator

lookup_indicator

Read-onlyIdempotent

Look up a threat indicator in OTX: an IPv4 or IPv6 address, a domain or hostname, a URL, an MD5/SHA1/SHA256 file hash, or a CVE id such as CVE-2021-4034. Returns the threat-intel pulses referencing that indicator plus observed-context fields, so it answers questions like which campaigns exploit a given CVE or whether an IP is known-malicious. type is auto-detected when omitted.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`type`	No	Force a type instead of auto-detecting. Case-insensitive and forgiving — "ip"/"ipv4"/"ip_address" all mean IPv4, "CVE" means cve, "md5"/"sha256"/"hash" all mean file. Leave it off unless auto-detection gets it wrong.
`indicator`	No	The value to look up: IPv4, IPv6, domain, hostname, URL, MD5/SHA1/SHA256 hash, or a CVE id such as CVE-2021-4034. Auto-detected — you do not need to pass `type`.

Output Schema

TableJSON Schema

Name	Required	Description
`hint`	No	What to try instead, when found is false
`type`	Yes	Detected or specified indicator type
`found`	Yes	False when OTX has no record of this indicator
`pulses`	Yes	Pulses containing this indicator
`reason`	No	Why nothing was returned, when found is false
`context`	No	Additional context fields from OTX API response
`indicator`	Yes	The indicator being looked up
`pulse_count`	Yes	Number of pulses referencing this indicator

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedAug 11, 2026

changedInput schema / properties / type / description

Previous value: -"Force a type instead of auto-detecting"New value: +"Force a type instead of auto-detecting. Case-insensitive and forgiving — \"ip\"/\"ipv4\"/\"ip_address\" all mean IPv4, \"CVE\" means cve, \"md5\"/\"sha256\"/\"hash\" all mean file. Leave it off unless auto-detection gets it wrong."

addedOutput schema / properties / found

Added value: +{
+  "description": "False when OTX has no record of this indicator",
+  "type": "boolean"
+}

addedOutput schema / properties / hint

Added value: +{
+  "description": "What to try instead, when found is false",
+  "type": "string"
+}

addedOutput schema / properties / reason

Added value: +{
+  "description": "Why nothing was returned, when found is false",
+  "type": "string"
+}

changedOutput schema / properties / type / enum

Previous value: -[
-  "IPv4",
-  "IPv6",
-  "domain",
-  "hostname",
-  "url",
-  "file"
-]New value: +[
+  "IPv4",
+  "IPv6",
+  "domain",
+  "hostname",
+  "url",
+  "file",
+  "cve"
+]

changedOutput schema / required

Previous value: -[
-  "indicator",
-  "type",
-  "pulse_count",
-  "pulses",
-  "context"
-]New value: +[
+  "found",
+  "indicator",
+  "type",
+  "pulse_count",
+  "pulses"
+]

Changed3 schema fields changedAug 3, 2026

changedInput schema / properties / indicator / description

Previous value: -"IPv4, domain, URL, or file hash (md5/sha1/sha256)"New value: +"The value to look up: IPv4, IPv6, domain, hostname, URL, MD5/SHA1/SHA256 hash, or a CVE id such as CVE-2021-4034. Auto-detected — you do not need to pass `type`."

changedInput schema / properties / type / enum

Previous value: -[
-  "IPv4",
-  "IPv6",
-  "domain",
-  "hostname",
-  "url",
-  "file"
-]New value: +[
+  "IPv4",
+  "IPv6",
+  "domain",
+  "hostname",
+  "url",
+  "file",
+  "cve"
+]

removedInput schema / required
```
Removed value: -[
-  "indicator"
-]
```

Changed1 schema field changedAug 3, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "indicator": "192.0.2.1"
-  },
-  {
-    "indicator": "example.com",
-    "type": "domain"
-  },
-  {
-    "indicator": "d41d8cd98f00b204e9800998ecf8427e",
-    "type": "file"
-  }
-]New value: +[
+  {
+    "indicator": "192.0.2.1"
+  },
+  {
+    "indicator": "example.com",
+    "type": "domain"
+  },
+  {
+    "indicator": "d41d8cd98f00b204e9800998ecf8427e",
+    "type": "file"
+  },
+  {
+    "indicator": "CVE-2021-4034",
+    "type": "cve"
+  }
+]

Changed2 schema fields changedMay 22, 2026

addedInput schema / examples

Added value: +[
+  {
+    "indicator": "192.0.2.1"
+  },
+  {
+    "indicator": "example.com",
+    "type": "domain"
+  },
+  {
+    "indicator": "d41d8cd98f00b204e9800998ecf8427e",
+    "type": "file"
+  }
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "context": {
+      "description": "Additional context fields from OTX API response",
+      "type": "object"
+    },
+    "indicator": {
+      "description": "The indicator being looked up",
+      "type": "string"
+    },
+    "pulse_count": {
+      "description": "Number of pulses referencing this indicator",
+      "type": "number"
+    },
+    "pulses": {
+      "description": "Pulses containing this indicator",
+      "items": {
+        "properties": {
+          "attack_ids": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "author": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "created": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "description": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "id": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "indicators_count": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "industries": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "malware_families": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "modified": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "otx_url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "tags": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "targeted_countries": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "type": {
+      "description": "Detected or specified indicator type",
+      "enum": [
+        "IPv4",
+        "IPv6",
+        "domain",
+        "hostname",
+        "url",
+        "file"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "indicator",
+    "type",
+    "pulse_count",
+    "pulses",
+    "context"
+  ],
+  "type": "object"
+}

First observedMay 11, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish readOnly, openWorld, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds valuable context beyond annotations: type auto-detection, the return payload (threat-intel pulses plus observed-context fields), and the forgiving nature of the type parameter. No contradictions are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three purposeful sentences: the first lists supported indicators, the second explains return value and use cases, and the third clarifies auto-detection. Every sentence adds distinct information with no repetition or filler, and the structure front-loads the core action.

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

Completeness5/5

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

Given the tool's simplicity (2 parameters, high schema coverage, output schema present, comprehensive annotations), the description is sufficient. It explains what the tool does, what it returns, and how the optional type parameter behaves. The presence of an output schema means detailed return fields need not be listed in the description.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining that 'type is auto-detected when omitted' and that the type parameter is only needed to override detection. It also gives concrete examples for each type, complementing the schema's enum and descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Look up') and resource ('threat indicator in OTX'), enumerating exact input types (IPv4/IPv6, domain, URL, hash, CVE). It clearly distinguishes the tool from siblings like get_pulse or search_pulses by focusing on indicator-to-pulse mapping rather than arbitrary search or pulse retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context via example questions ('which campaigns exploit a given CVE', 'whether an IP is known-malicious') that indicate suitable use cases. It does not explicitly name alternative tools or say when not to use this tool, but the examples make the intended usage obvious, placing it just below an explicit exclusion list.

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

All Alienvault Otx tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.