Intel Threadlinqs MCP

Threat Hunting Bundle

get_threat_hunting_bundle

Read-onlyIdempotent

Scope a threat hunt with one call by retrieving a bundled dossier of threat details, similar threats, simulations, and infrastructure pivots for a given threat ID.

Instructions

Flagship one-call hunting dossier for a threat: threat detail + similar threats + simulations + infrastructure pivots, composed server-side. Best single tool to scope a hunt around one threat. Every section is bounded so the bundle fits in one response — raise simulation_limit / pivot_limit, or call get_infrastructure_pivots and get_threat directly, when you need the full lists.

Input Schema

TableJSON Schema

Name	Required	Description
`shape`	No	"v1" (default, unchanged nested envelope) \| "canonical" (flat, stably-named, SMALLER — recommended for programmatic consumers) \| "both". In canonical: technique ids are a top-level `ttps` array, sectors/regions use ONE spelling, and every array key is ALWAYS an array (never null, never an object). In v1, `similar_threats` and `infrastructure_pivots` are handler envelopes (objects) while `threat.similar_threats` is a flat array — if you are writing a parser, use canonical.
`threat_id`	Yes	Threat ID (e.g. TL-2026-0042)
`pivot_limit`	No	Infrastructure pivots to embed, 1-200 (default 25). One threat can carry 150+; get_infrastructure_pivots returns the full set.
`simulation_limit`	No	Playbooks to embed, 1-20 (default 3).

Output Schema

TableJSON Schema

Name	Required	Description
`iocs`	No	canonical: FLAT array. (In v1 this is an object keyed by category under threat.iocs.)
`ttps`	No	Canonical MITRE technique ids, present in BOTH shapes.
`_shape`	No
`counts`	No	canonical: a denominator for every array key.
`threat`	No
`regions`	No
`sectors`	No
`_envelope`	No	Shape manifest — announces that shape="canonical" exists.
`canonical`	No	Present only under shape="both".
`threat_id`	No
`simulations`	No
`ttp_details`	No
`similar_threats`	No	v1: handler envelope {source_threat_id, count, similar[]} — an OBJECT, not an array.
`infrastructure_pivots`	No	v1: handler envelope {threat_id, infrastructure_pivots[], coverage{}} — an OBJECT.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed16 schema fields changedv8.2.1Aug 24, 2026

addedInput schema / properties / pivot_limit

Added value: +{
+  "description": "Infrastructure pivots to embed, 1-200 (default 25). One threat can carry 150+; get_infrastructure_pivots returns the full set.",
+  "type": "integer"
+}

addedInput schema / properties / shape

Added value: +{
+  "description": "\"v1\" (default, unchanged nested envelope) | \"canonical\" (flat, stably-named, SMALLER — recommended for programmatic consumers) | \"both\". In canonical: technique ids are a top-level `ttps` array, sectors/regions use ONE spelling, and every array key is ALWAYS an array (never null, never an object). In v1, `similar_threats` and `infrastructure_pivots` are handler envelopes (objects) while `threat.similar_threats` is a flat array — if you are writing a parser, use canonical.",
+  "type": "string"
+}

addedInput schema / properties / simulation_limit

Added value: +{
+  "description": "Playbooks to embed, 1-20 (default 3).",
+  "type": "integer"
+}

addedOutput schema / properties / _envelope

Added value: +{
+  "description": "Shape manifest — announces that shape=\"canonical\" exists.",
+  "type": "object"
+}

addedOutput schema / properties / _shape
```
Added value: +{
+  "type": "object"
+}
```

addedOutput schema / properties / canonical

Added value: +{
+  "description": "Present only under shape=\"both\".",
+  "type": "object"
+}

addedOutput schema / properties / counts

Added value: +{
+  "description": "canonical: a denominator for every array key.",
+  "type": "object"
+}

addedOutput schema / properties / infrastructure_pivots / description

Added value: +"v1: handler envelope {threat_id, infrastructure_pivots[], coverage{}} — an OBJECT."

addedOutput schema / properties / iocs

Added value: +{
+  "description": "canonical: FLAT array. (In v1 this is an object keyed by category under threat.iocs.)",
+  "items": {
+    "additionalProperties": true,
+    "properties": {
+      "category": {
+        "type": "string"
+      },
+      "type": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "value": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / regions

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / sectors

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / similar_threats / description

Added value: +"v1: handler envelope {source_threat_id, count, similar[]} — an OBJECT, not an array."

addedOutput schema / properties / threat_id
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / ttp_details

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "name": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "tactic": {
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / ttps

Added value: +{
+  "description": "Canonical MITRE technique ids, present in BOTH shapes.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedOutput schema / required
```
Removed value: -[
-  "threat"
-]
```

Changed1 schema field changedv8.1.1Aug 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "infrastructure_pivots": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "similar_threats": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "simulations": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "threat": {
+      "additionalProperties": true,
+      "properties": {
+        "id": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "threat"
+  ],
+  "type": "object"
+}

First observedv0.1.0Jul 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds genuinely useful behavioral context: the bundle is composed server-side, every section is bounded so the response fits in one call, and limits can be raised or fallback tools used. It does not mention latency or payload-size expectations, but it goes well beyond the annotations.

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?

Three concise sentences; the first explains composition, the second gives the primary use case, and the third explains limits and when to use alternatives. Every sentence earns its place, and the description is front-loaded with the most important information.

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?

For a one-call bundle tool with an output schema and 100% parameter schema coverage, the description covers what the bundle contains, why and when to use it, how to control response size, and what to call instead for full lists. Nothing needed for correct selection or invocation is left out.

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 parameters are already well documented. The description adds extra value by explicitly tying simulation_limit and pivot_limit to the bounded-list behavior and by naming the fallback tools to get complete lists. This is more than the baseline, though each parameter's precise meaning still comes from the schema.

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

Purpose4/5

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

The description names a specific verb and resource: a one-call hunting dossier that composes threat detail, similar threats, simulations, and infrastructure pivots server-side. It clearly differentiates from get_threat and get_infrastructure_pivots via the fallback note, but it does not explicitly distinguish from the closely titled sibling get_threat_bundle, so it misses full sibling differentiation.

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

Usage Guidelines5/5

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

The description explicitly says this is the best single tool to scope a hunt around one threat and gives concrete when-not usage: raise simulation_limit/pivot_limit, or call get_infrastructure_pivots and get_threat directly when full lists are needed. This is clear, actionable selection guidance.

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

Install Server

Other Tools

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/threadlinqs-cmd/intelthreadlinqs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server