Intel Threadlinqs MCP

Enrichment Overview

get_enrichment_overview

Read-onlyIdempotent

Check the health and coverage of threat intelligence enrichment lanes, including hit rates and snapshot timeliness. Understand which data sources are measured or missing.

Instructions

Health and coverage of the enrichment LANES feeding the platform, one row each: cve_details, threat_iocs, detections, mitre_attack, c2_intel, dns_enrichment, tl_osint_scan, osint_blocklist_liveness. EPSS and KEV are NOT separate lanes - they are fields inside cve_details (whose hit_rate is the share of CVEs carrying both CVSS v3 and EPSS), and there is no IOC-reputation lane; the nearest signals are osint_blocklist_liveness and tl_osint_scan. Each lane's hit_rate has its OWN definition (they are not comparable to each other) and coverage_basis distinguishes 'measured_zero' from 'not_measured' - c2_intel really is 0% corpus coverage, because c2_correlations_v2 has no populated threat_id. This is a nightly snapshot: read as_of/stale_hours before treating it as current.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	States which advertised sources are lanes and which are fields of a lane.
`as_of`	No	Newest row timestamp - this is a nightly snapshot, not a live read.
`sources`	No
`summary`	No
`stale_hours`	No

Schema Changelog

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

Changed19 schema fields changedv8.2.1Aug 24, 2026

addedOutput schema / properties / as_of

Added value: +{
+  "description": "Newest row timestamp - this is a nightly snapshot, not a live read.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / note

Added value: +{
+  "description": "States which advertised sources are lanes and which are fields of a lane.",
+  "type": "string"
+}

addedOutput schema / properties / sources / items / properties / avg_enrichment_fields
```
Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
```

addedOutput schema / properties / sources / items / properties / coverage_basis

Added value: +{
+  "description": "'measured' | 'measured_zero' (really zero) | 'not_measured' (never computed) - the two used to be indistinguishable.",
+  "type": "string"
+}

addedOutput schema / properties / sources / items / properties / coverage_pct

Added value: +{
+  "description": "Share of the corpus this lane reaches. Read WITH coverage_basis.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / sources / items / properties / hit_rate / description

Added value: +"PER-LANE definition, not comparable across lanes. NULL = not measurable for this lane."

changedOutput schema / properties / sources / items / properties / hit_rate / type
```
Previous value: -"number"New value: +[
+  "number",
+  "null"
+]
```

addedOutput schema / properties / sources / items / properties / hit_rate_basis

Added value: +{
+  "description": "'measured' | 'not_measured'.",
+  "type": "string"
+}

addedOutput schema / properties / sources / items / properties / last_event_time
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

addedOutput schema / properties / sources / items / properties / provenance

Added value: +{
+  "description": "'native_d1' = computed from our own tables; 'harness_tl_osint_scan' = community-sourced, corroborating only.",
+  "type": "string"
+}

addedOutput schema / properties / sources / items / properties / source / description
```
Added value: +"Lane name (alias of source_name)."
```
addedOutput schema / properties / sources / items / properties / source_name
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / sources / items / properties / unique_entities
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / sources / items / properties / updated_at
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / stale_hours

Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}

addedOutput schema / properties / summary / properties / avg_hit_rate / description
```
Added value: +"Averaged ONLY over lanes reporting a real hit_rate."
```
changedOutput schema / properties / summary / properties / avg_hit_rate / type
```
Previous value: -"number"New value: +[
+  "string",
+  "null"
+]
```

addedOutput schema / properties / summary / properties / measured_zero_coverage

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

addedOutput schema / properties / summary / properties / unmeasured_coverage

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

Changed2 schema fields changedv8.1.1Aug 3, 2026

addedOutput schema / properties / sources

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "properties": {
+      "hit_rate": {
+        "type": "number"
+      },
+      "source": {
+        "type": "string"
+      },
+      "total_events": {
+        "type": "integer"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / summary

Added value: +{
+  "additionalProperties": true,
+  "properties": {
+    "avg_hit_rate": {
+      "type": "number"
+    },
+    "total_events": {
+      "type": "integer"
+    },
+    "total_sources": {
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

First observedv0.1.0Jul 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The annotations already state that this is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond those annotations: the output is a nightly snapshot, the data is grouped into specific lanes, coverage_basis distinguishes 'measured_zero' from 'not_measured', and c2_intel's 0% is explained as a true omission rather than a measurement artifact. This is exactly the kind of interpretive detail an agent needs to avoid misreading the data.

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 information-dense but every sentence earns its place: the row set, the non-lane caveats, the hit_rate caveat, the measured-zero explanation, and the freshness warning. It is front-loaded with the main purpose and then adds necessary exclusions and interpretation guidance. There is no redundant filler.

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 no-parameter, output-driven tool, this description covers all the essential context an agent needs: what the overview reports, how the rows/lines are defined, what fields like hit_rate and coverage_basis actually mean, and how to check freshness. The output schema is already available, so the description does not need to re-list the return shape. No important usage aspect seems missing.

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?

The tool has zero parameters, so there is no schema surface for the description to clarify. The description instead clarifies the semantics of the returned object, which is more than enough for an empty input schema. Since there are no parameters to describe, the baseline of 4 is appropriate.

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 very specific resource: 'Health and coverage of the enrichment LANES feeding the platform,' and immediately enumerates the exact rows/groups the tool returns. It also clarifies what is not included (EPSS and KEV are fields inside cve_details, not separate lanes), which removes ambiguity an agent would otherwise have when deciding whether this matches the user's request.

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 gives strong context on how to interpret the result: values like coverage_basis have special meanings, hit_rate definitions vary by lane, and c2_intel's 0% is a true measured zero. It also cautions the agent to read as_status/stale_hours because this is a nightly snapshot. It does not explicitly name alternative sibling tools or a when-not-to-use condition, so it falls just short of a 5.

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