What can you do with this server?

This server exposes the Tenable Identity Exposure (TIE) REST API as MCP tools for LLM-driven security monitoring, investigation, and analysis of Active Directory environments. It is read-only by default; writes require --allow-writes, and credential/sensitive endpoints are blocked or redacted. * Discover and query resources: tie_catalog lists API resources and paths; tie_request makes raw HTTP calls to any relative TIE endpoint; tie_resource_action performs generic CRUD on catalogued resources subject to write restrictions. * Monitor security activity: tie_recent_activity gives a unified IoE/IoA timeline; tie_alerts lists alerts for a profile; tie_attacks lists IoA attack instances by infrastructure, directory, hostname, or IP. * Assess security posture: tie_profiles lists security profiles; tie_scores returns per-directory security scores; tie_topology shows AD topology (domains, forests, trusts). * Investigate IoE deviances: tie_deviances, tie_deviances_by_checker, tie_deviances_by_directory, and tie_deviances_bulk retrieve deviances by checker, directory, time window, or across all checkers; tie_checkers_summary summarizes IoE checker definitions. * Search AD data: tie_search_ad_objects locates users, computers, groups, and OUs by name or DN fragment; tie_search_events searches AD security events within a date range. * User context: tie_whoami returns identity, roles, and permissions for the API key user. Safety restrictions include blocking credential endpoints, preventing writes to sensitive configuration endpoints and deviance records, redacting password fields, and accepting only server-relative paths to prevent API key leakage. Deployment is flexible via Python venv, uv, or Docker with configurable TIE URL, API key, and SSL verification.

How do I use tenable-identity-exposure-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tenable-identity-exposure-mcp show recent activity for the last 6 hours" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

tenable-identity-exposure-mcp

by ukkugh

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Tenable Identity Exposure MCP Server

An MCP server exposing the Tenable Identity Exposure (TIE, formerly Tenable.ad) REST API as tools for LLM clients. Built on FastMCP from the official mcp SDK.

Verified end-to-end against a live TIE SaaS instance (v3.120.1).

⚠️ Disclaimer: This is not an officially supported Tenable project. It was built with assistance from Claude — treat its output as a starting point and validate responses against the Tenable console before acting on them.

Origin: this repository builds on knethteo/tenable-identity-exposure-mcp by Kenneth Teo, MIT-licensed. See LICENSE for the original copyright.

Credentials are never stored in this repository

There is no API key here, and there never has been — .env is git-ignored and absent from the history. Every user supplies their own key at runtime; see Configuration. TIE API keys are per-user, do not expire, and inherit the issuing account's console permissions, so share a single key only if you are willing to lose per-person attribution in the TIE audit log. Prefer one least-privilege key per person.

Tools

Tool	Description
`tie_catalog`	List available resources (flat + nested) — call this first
`tie_request`	Raw HTTP call to any endpoint (`method`, `path`, `params`, `body`)
`tie_resource_action`	Generic CRUD (`list`/`get`/`create`/`update`/`delete`) on flat resources
`tie_recent_activity`	Unified IoE+IoA timeline for the last N hours (one call)
`tie_profiles`	List security profiles (IoE/IoA data is profile-scoped)
`tie_scores`	Per-directory security scores for a profile
`tie_topology`	AD topology (domains, forests, trusts) for a profile
`tie_attacks`	IoA attack instances (requires `resource_type` + `resource_value`)
`tie_alerts`	Alerts for a profile
`tie_deviances`	IoE deviant AD objects for a checker within a time window
`tie_deviances_by_checker`	Full IoE deviances for a checker (no date filter)
`tie_deviances_by_directory`	Full IoE deviances for a directory (no date filter)
`tie_search_events`	Search AD security events in a date range
`tie_search_ad_objects`	Search AD objects (users/computers/groups/OUs)
`tie_whoami`	Current user identity, roles, permissions
`tie_checkers_summary`	All IoE checker definitions, essential fields only (no description blobs)
`tie_deviances_bulk`	All active IoE deviances in a few paginated calls

Read-only by default

Non-GET calls are refused unless the server is started with --allow-writes (or TIE_ALLOW_WRITES=true). This applies to tie_request and to the create/update/delete actions of tie_resource_action.

Some endpoints are never writable, even with --allow-writes: users, roles, saml-configuration, ldap-configuration, syslogs, email-notifiers, lockout-policy, application-settings, attack-type-configuration, license, infrastructures, directories, and the uncatalogued /api/login, /api/logout, /api/relays. These reconfigure authentication, access control, or alert/log forwarding, change the monitored AD topology, or — in the case of /api/login — would turn the server into a credential-testing oracle for the console. The block covers nested routes too, so PATCH /api/infrastructures/{i}/directories/{d} is refused, not just the top-level path.

Deviance records are never writable either. PATCH/PUT/DELETE is refused on /api/profiles/{p}/checkers/{c}/deviances and /api/profiles/{p}/checkers/{c}/ad-objects/{a}/deviances, alongside the single-deviance route the topology block already covered. Those two bulk routes close every deviance for a checker or an AD object in one call: silently erasing findings is the worst thing this server could be talked into doing. POST on the same paths is a search and stays available — TIE models several reads as POST.

Credential endpoints are never readable either, by any method or tool and regardless of --allow-writes:

Endpoint	Why
`/api/api-key`	returns the console API key this server authenticates with
`/api/report-access-token`	returns the embedded-report access token
`/api/relays/linking-key`	returns the relay enrolment secret

Read-only mode is worth nothing if the model can read the key: TIE API keys do not expire and carry the issuing account's full console permissions, so anyone who sees the transcript could drive the console directly. tie_catalog declares these endpoints as blocked so the model is told once rather than retrying around one refusal at a time.

Two more endpoints stay readable but come back redacted. Per Tenable's published OpenAPI spec, GET /api/ldap-configuration returns searchUserPassword and GET /api/application-settings returns smtpAccountPassword. Both were already write-protected, but that only guarded writes — reading either one handed the model a live credential, and in the LDAP case searchUserDN + searchUserPassword is a complete Active Directory service-account bind pair, not merely a console one.

Blocking them outright would cost real audit capability (whether LDAP is enabled, which SMTP relay is configured, the log-retention window), so the endpoints remain readable and only the credential fields are replaced:

{ "enabled": true, "url": "ldaps://dc1.example",
  "searchUserDN": "CN=svc-tie,OU=Service,DC=example",
  "searchUserPassword": "<redacted: credential; this server never returns it>" }

The redaction matches field names (password, passphrase, secret, privatekey) so a credential field Tenable adds later is covered without a code change, and it is applied only to those two endpoints — Active Directory data legitimately carries PasswordNeverExpires, passwordLastSet and "Password not required", and those are the findings this server exists to report, not secrets to hide. A field that is absent or empty is left as-is, so "no bind password is configured" stays a readable answer.

tie_request also refuses absolute URLs — only server-relative paths such as /api/about are accepted, so the API key cannot be sent to another host.

None of this replaces server-side authorization. Scope the API key to a least-privilege TIE role as well.

Time windows, profiles, and token budget

Time-aware tools (tie_recent_activity, tie_deviances) accept a relative hours=N window or explicit date_start/date_end. All timestamps are UTC.
IoE/IoA data is profile-scoped. The API does not expose which profile your console has selected, so pass profile_id explicitly — use tie_profiles to list them.
By default, deviance/object results are slimmed: descriptions are rendered from their templates and oversized attribute values (SID lists, member dumps) are dropped. Pass verbose=true for the full raw payload. This applies to every deviance tool, tie_deviances_bulk included — at its default caps (4,000 records) the raw payload runs to tens of megabytes.
Results that were cut short say so. Anything that stops at a page cap, a result cap, or a failed sub-lookup reports it in a notes array, and a directory list that cannot be read is an error rather than an empty timeline. Read notes before concluding that something does not exist.

Related MCP server: Tenable Identity Exposure MCP Server

Configuration

Set via environment variables (or the equivalent CLI flags):

Variable	Flag	Description
`TIE_URL`	`--tie-url`	Base URL, e.g. `https://your-client.tenable.ad`
`TIE_API_KEY`	`--tie-api-key`	API key (see below)
`TIE_VERIFY_SSL`	`--no-verify-ssl`	`true` (default); `false` for self-signed certs
`TIE_ALLOW_WRITES`	`--allow-writes`	`false` (default) — see Read-only by default
—	`--host` / `--port`	Bind address for `sse`/`http`; `127.0.0.1:8000` by default
—	`--allowed-host`	Extra `Host` header value to accept on `sse`/`http` (repeatable) — see below

Auth uses the X-API-Key header.

Getting the API key: TIE console → user profile icon (top right) → My Account / Preferences → API key. It is a per-user setting, the same path on SaaS and on-premises. The key inherits the issuing account's role permissions, so create a dedicated least-privilege service account for it.

Not a Tenable Vulnerability Management key. TIE uses a single opaque key in an x-api-key header against your own console hostname (https://<client>.tenable.ad). Tenable VM / Tenable One use an accessKey+secretKey pair in an X-ApiKeys header against cloud.tenable.com. They are not interchangeable — and if Tenable Cloud Data Collection is enabled, TIE auto-creates tie-{username}-{random} accounts inside your Tenable VM container that will not work here.

Install & run

Setting this up for the first time? ONBOARDING.md walks through it end to end on Windows, Linux, and macOS — install, getting an API key, registering with Claude Code, and a set of checks to confirm it works. The rest of this section is the short version.

python -m venv .venv && . .venv/bin/activate
pip install -e .

cp .env.example .env   # fill in TIE_URL and TIE_API_KEY

# stdio (Claude Desktop / Claude Code)
set -a; . ./.env; set +a
tenable-tie-mcp

# or network transports (bind 127.0.0.1 by default — they have no auth of
# their own, so widen --host only behind an authenticating proxy)
tenable-tie-mcp --transport sse --port 8000
tenable-tie-mcp --transport http --port 8000

Reaching a network transport from another host

FastMCP validates the Host header against an allow-list that contains only loopback names, so --host alone is not enough: a server bound to 0.0.0.0 answers 421 Misdirected Request to any client that addresses it by IP or DNS name. Name the host your clients actually use:

# clients connect to http://tie-mcp.internal:8000/sse
tenable-tie-mcp --transport sse --host 0.0.0.0 --port 8000 \
                --allowed-host tie-mcp.internal:8000

Passing --host <name> (rather than 0.0.0.0) adds that name automatically. Loopback stays accepted either way, and the server logs a warning whenever the allow-list is widened — this is a Host header check, not authentication. Anyone who can reach the port inherits the configured API key's permissions, so put it behind an authenticating proxy.

Tests

uv pip install --group dev
pytest
mypy

Running with uv / uvx (alternative to a manual venv)

uv can manage the environment for you. uv is the full tool; uvx (alias for uv tool run) runs a package in a throwaway env, like npx. Both need uv installed (brew install uv).

# uv run: resolves deps from pyproject.toml into a managed .venv, then runs
uv run tenable-tie-mcp

# uvx: run ephemerally from the project path, nothing persisted
uvx --from . tenable-tie-mcp

Claude Desktop / Claude Code config

Use the full path to the executable. Claude Desktop does not launch from your shell, so it does not inherit your PATH — a bare tenable-tie-mcp will fail with "command not found" unless the tool is on the system PATH (e.g. a pipx install).

For a venv install, point at the venv's launcher:

{
  "mcpServers": {
    "tenable-tie": {
      "command": "/absolute/path/to/tenable-ie-mcp/.venv/bin/tenable-tie-mcp",
      "env": {
        "TIE_URL": "https://your-host.tenable.ad",
        "TIE_API_KEY": "your-key"
      }
    }
  }
}

Find the exact path with echo "$PWD/.venv/bin/tenable-tie-mcp" from the project root. See claude_desktop_config.sample.json for a complete example.

If you installed globally with pipx install . (or uv tool install), the bare "command": "tenable-tie-mcp" works because it lands on the system PATH.

With uv (alternative)

Point command at the full path of uv (which uv, e.g. /opt/homebrew/bin/uv) and let it manage the environment:

{
  "mcpServers": {
    "tenable-tie": {
      "command": "/opt/homebrew/bin/uv",
      "args": ["run", "--directory", "/absolute/path/to/tenable-ie-mcp", "tenable-tie-mcp"],
      "env": {
        "TIE_URL": "https://your-host.tenable.ad",
        "TIE_API_KEY": "your-key"
      }
    }
  }
}

Docker

docker compose up --build   # reads TIE_URL / TIE_API_KEY from environment

Example prompts

"Show me IoE and IoA activity in the last 12 hours." → tie_recent_activity
"Which security profiles exist?" → tie_profiles
"List the monitored directories and their security scores."
"Show the latest IoA attacks against directory 8."
"What IoE deviances appeared for checker 15 in the last day?" → tie_deviances
"Show unread alerts for profile 2."

Notes

profile_id defaults to 1 (the default Tenable profile) in the convenience tools.
Attacks must be scoped: resource_type ∈ infrastructure|directory|hostname|ip and resource_value is the id or name/ip.
Non-JSON responses are returned as {"content_type": ..., "text": ...} rather than crashing.
Scoring and prioritization: TIE checkers carry no native severity or criticality score — the published checker schema has no such field. remediationCost is the only effort hint, and note that it comes back as an integer (the console renders the easy / medium / hard labels itself) and Tenable marks it deprecated, so it is a weak basis for ranking on its own. If your workflow requires AES (Asset Exposure Score) or ACR (Asset Criticality Rating) — for example, to rank affected identities by business risk — connect your environment to Tenable One. Tenable One aggregates data across TIE, Tenable Vulnerability Management, and other sources to produce unified AES/ACR scores that can be surfaced here via the API.

Available Tools

17 tools

tie_alertsA

List alerts for a security profile.

Args: profile_id: Security profile id (default 1). page: Page number (1-based). per_page: Results per page. archived: Optionally filter by archived status (True/False).

Inputs: page, archived, per_page, profile_id.

tie_attacksA

List IoA attack instances for a resource within a profile.

The TIE API requires scoping attacks to a resource. For example, to see attacks against directory id 8: resource_type="directory", resource_value="8".

Args: resource_type: What resource_value refers to — infrastructure, directory, hostname, or ip. resource_value: The id (for infrastructure/directory) or name/ip value to scope to. profile_id: Security profile id (default 1). attack_type_ids: Optional list of attack type ids to filter (e.g. DCSync, Kerberoasting). date_start: Optional ISO 8601 start of date range. date_end: Optional ISO 8601 end of date range. include_closed: Include closed attacks (default False). limit: Max results (default 50). order: Sort order by date, "desc" (newest first) or "asc". search: Optional free-text search filter.

Inputs: resource_type (required), resource_value (required), limit, order, +6 more.

tie_catalogA

List all available Tenable Identity Exposure API resources and their paths.

Call this first to discover what resources exist before using other tools.

Inputs: no named parameters. Returns: result

tie_checkers_summaryA

Get all IoE checker definitions — essential fields only, no description blobs.

Returns id, codename, name, categoryId, and remediationCost for every checker. This is ~100x smaller than tie_resource_action resource="checkers", which embeds multi-KB description/recommendation/vulnerabilityDetail blobs per checker (~500 KB total for ~64 checkers). Use this to enumerate checkers, build a remediation plan, or map deviance checkerId values to human-readable names.

Note: TIE checkers carry remediationCost (easy/medium/hard) but no native severity/ criticality score. For AES (Asset Exposure Score) or ACR (Asset Criticality Rating) scoring, connect to Tenable One — see the README for details.

Inputs: no named parameters.

tie_deviancesA

Find AD objects with IoE deviances for a checker within a time window.

This is the time-filterable deviance query (server-side dateStart/dateEnd via the checker's ad-objects/search endpoint). Provide hours for a relative window (e.g. hours=12) or explicit date_start/date_end. With neither, defaults to the last 24h.

Args: checker_id: IoE checker id (see resource="checkers"). profile_id: Security profile id (default 1). Note: your console may use a non-default profile — call tie_profiles to list them. directory_ids: Restrict to these directory ids (default: all directories in scope). hours: Relative look-back window in hours (e.g. 12). Ignored if date_start given. date_start: Explicit ISO 8601 UTC start (e.g. "2026-07-07T16:00:00.000Z"). date_end: Explicit ISO 8601 UTC end (default: now). reasons: Optional reason ids to filter (see /api/profiles/{id}/checkers/{id}/reasons). show_ignored: Include deviances that are currently ignored (default False). page: Page number (1-based). per_page: Results per page. verbose: If False (default), truncate giant attribute values.

Inputs: checker_id (required), page, hours, reasons, +7 more.

tie_deviances_bulkA

Fetch all IoE deviances in a few paginated calls (bulk alternative to per-checker fan-out).

Uses GET /api/deviances/changed with cursor pagination to pull deviances across all checkers at once — typically 1–5 API calls instead of one call per checker (~64). This is the recommended starting point for remediation-plan workflows.

Deviances include checkerId and adObjectId (numeric ID, not display name). Use tie_checkers_summary to map checkerId → checker name, and tie_search_ad_objects to resolve adObjectId → object name if needed.

Args: profile_id: Filter to a specific profile id (client-side). None = include all profiles. resolved: Include resolved/closed deviances (default False = active only). batch_size: Records per API page (default 200). max_batches: Safety cap on pagination loops (default 20 = up to 4000 records).

Inputs: resolved, batch_size, profile_id, max_batches.

tie_deviances_by_checkerA

List IoE deviances for a given checker within a profile (full detail, no date filter).

For a time-bounded view use tie_deviances(hours=...) or tie_recent_activity instead. The TIE API models this as a POST with a filter expression body; an empty expression returns all deviances for the checker.

Args: checker_id: IoE checker id (see tie_resource_action resource="checkers"). profile_id: Security profile id (default 1). page: Page number (1-based). per_page: Results per page. expression: Optional filter expression object. Defaults to {} (no filter). verbose: If False (default), render descriptions and drop giant attribute values to save tokens. Set True for the full raw payload.

Inputs: checker_id (required), page, verbose, per_page, +2 more.

tie_deviances_by_directoryA

List IoE deviances for a specific directory (full detail, no date filter).

Args: infrastructure_id: Infrastructure (forest) id — see resource="infrastructures". directory_id: Directory id — see resource="directories". page: Page number (1-based). per_page: Results per page. verbose: If False (default), render descriptions and drop giant attribute values.

Inputs: directory_id (required), infrastructure_id (required), page, verbose, +1 more.

tie_profilesA

List security profiles (id + name).

IoE/IoA data is scoped to a profile. The console has a selected profile that the API does not expose, so pass the right profile_id explicitly to other tools.

Inputs: no named parameters.

tie_recent_activityA

Unified recent-activity timeline of IoE alerts and IoA attacks in one call.

Answers questions like "show me IoE/IoA in the last 12 hours". IoE is sourced from the profile's alert feed (time-ordered) and each in-window alert is enriched with its deviance detail (checker + rendered description). IoA is sourced from the attacks endpoint per directory. Results are merged and sorted newest-first. All timestamps are UTC.

Args: hours: Look-back window in hours (default 12). profile_id: Security profile id (default 1). See tie_profiles. include_ioe: Include IoE deviance alerts (default True). include_ioa: Include IoA attacks (default True). directory_ids: Restrict to these directory ids (default: all in scope). max_items: Cap on items per category — IoE and IoA are budgeted separately (default 50). The IoA cap applies across all directories, not per directory; any truncation is reported in notes. verbose: If False (default), attribute values are slimmed.

Inputs: hours, verbose, max_items, profile_id, +3 more.

tie_requestA

Make a direct HTTP call to any Tenable Identity Exposure API endpoint.

Only server-relative paths are accepted; absolute URLs are refused so the API key cannot be sent to another host. Non-GET methods require the server to have been started with --allow-writes. Credential endpoints are refused for every method, including GET.

Args: method: HTTP method (GET, POST, PUT, PATCH, DELETE). path: API path, e.g. "/api/directories" or "/api/attacks/123". params: Optional query string parameters as a dict. body: Optional request body as a dict (used with POST/PUT/PATCH).

Returns: Parsed JSON response from the TIE API.

Inputs: path (required), method (required), body, params.

tie_resource_actionA

Perform CRUD operations on a TIE resource.

Args: resource: Resource name from tie_catalog (e.g. "directories", "attacks", "users"). action: Operation — list, get, create, update, or delete. id: Resource ID for get/update/delete operations. body: Request body for create/update operations. params: Optional query parameters (e.g. pagination, filters).

Writes (create/update/delete) require the server to have been started with --allow-writes, and are refused outright for protected resources such as users, roles, the authentication settings, and the monitored AD topology. Credential resources are refused for every action, including list/get.

Examples: List all directories: resource="directories", action="list" Get directory #5: resource="directories", action="get", id=5 List recent attacks: resource="attacks", action="list", params={"page": 1} Create a dashboard: resource="dashboards", action="create", body={...}

Inputs: resource (required), id, body, action, +1 more.

tie_scoresA

Get per-directory security scores for a profile.

Returns a list of {directoryId, score} reflecting the AD security posture (higher is better; scores reflect outstanding IoE deviances).

Args: profile_id: Security profile id (default 1).

Inputs: profile_id.

tie_search_ad_objectsA

Find Active Directory objects whose name or DN contains query.

IMPORTANT: /api/ad-objects has no server-side search. It returns the last known state of every object, cursor-paginated (~1000 per page, roughly 2 MB each on a small forest). Filtering here is therefore CLIENT-SIDE, and only objects within the scanned prefix can match — raise max_scanned to widen the sweep, and read scanned/truncated in the result before concluding that something does not exist.

For deviance investigation prefer tie_deviances / tie_deviances_by_checker, which are filtered server-side.

Args: query: Substring to look for, case-insensitive. Matched against objectId and the naming attributes (cn, name, displayName, sAMAccountName, distinguishedName, userPrincipalName) — not against bulk blobs like ntSecurityDescriptor, which would produce meaningless hits. directory_id: Restrict to one directory (see resource="directories"). object_class: Substring of the objectClass attribute, e.g. "user", "computer", "group", "organizationalUnit". Note this is the LDAP objectClass; the object's own type field is the data source (LDAP or SYSVOL), not the object category. max_results: Stop after this many matches (default 50). max_scanned: Cap on objects fetched while searching (default 5000). timestamp: Optional ISO 8601 UTC point in time; defaults to now. verbose: If False (default), oversized attribute values are dropped.

Inputs: query (required), verbose, timestamp, max_results, +3 more.

tie_search_eventsA

Search AD security events within a date range.

Args: directory_ids: One or more directory ids to search (see resource="directories"). date_start: ISO 8601 start of range, e.g. "2026-07-01T00:00:00.000Z". date_end: ISO 8601 end of range. profile_id: Security profile id (default 1). expression: Optional filter expression object. Defaults to {} (no filter). order: Optional ordering object, e.g. {"column": "date", "direction": "desc"}.

Inputs: date_end (required), date_start (required), directory_ids (required), order, +2 more.

tie_topologyA

Get the Active Directory topology (domains, forests, and trust relationships).

Args: profile_id: Security profile id (default 1).

Inputs: profile_id.

tie_whoamiA

Get the current user's identity, roles, and permissions (from the API key).

Inputs: no named parameters.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

Deploy Server

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

TDQS

A3.9/5.0

Scored 2026-08-07 03:28 across 17 tools

Disambiguation3/5

Several tools overlap in purpose: tie_deviances, tie_deviances_by_checker, tie_deviances_by_directory, and tie_deviances_bulk all query deviances with different parameterizations. tie_resource_action and tie_request both provide generic API access, and tie_recent_activity overlaps with tie_alerts and tie_attacks. Descriptions mitigate some ambiguity, but agents may struggle to pick the right tool for time-bounded deviance queries.

Naming Consistency3/5

All tools share the 'tie_' prefix, but naming patterns are inconsistent: some are verb_noun (tie_search_events), some are noun_phrase (tie_checkers_summary, tie_deviances_bulk), and a few are single nouns (tie_profiles, tie_catalog). The lack of a uniform verb_noun or action-first convention makes the set feel less predictable.

Tool Count3/5

With 17 tools, the set sits just above the ideal 3-15 range. The sheer number of deviance query variants (four) and generic utilities (catalog, request, resource_action) inflate the count, though the complexity of the TIE API partially justifies the breadth.

Completeness4/5

The tool surface covers most core workflows: discovery, topology, scores, events, deviances, attacks, and alerts. Generic CRUD via tie_resource_action fills in gaps. However, there is no explicit tool for mutating deviance state (e.g., ignore or resolve), and the generic tools may not expose all such endpoints cleanly, representing a notable gap.

Maintenance

ActivityInactive

ResponsivenessOutdated data

Resources

Related MCP Connectors

ambiscribe
io.ambiscribe
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Monitoring Observability Security
2
https://mcp.ambiscribe.io/mcp
Crimson Crawler
com.crimsoncrawler
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Security Search Research & Data
1
https://crimsoncrawler.com/mcp/v1
Midkernel Threat IntelA
com.midkernel
Free, read-only public-source threat intel over MCP. No account or API key.
Security Open Data Research & Data
61
https://www.midkernel.com/security/app/mcp/threat-intel
Plato's KallipolisA
io.github.handongzhen101-jpg
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
Agent Orchestration AI & Machine Learning
61
https://platoskallipolis.com/api/mcp

Related MCP Servers

tie-mcp-server
Security Monitoring
taherkaraki
A
license
C
quality
C
maintenance
MCP server for the Tenable Identity Exposure API, providing 131 tools for complete API coverage with multi-tenant support and granular security controls.
Updated 4 months ago (2026-07-28 10:47 UTC)
100
31 npm
17
MIT
Tenable Identity Exposure MCP
Security Observability
knethteo
A
license
A
quality
D
maintenance
Exposes the Tenable Identity Exposure (TIE) REST API as tools for LLM clients, enabling queries on security profiles, activity timelines, AD objects, and more.
Updated 3 months ago (2026-08-06 04:11 UTC)
15
5
MIT
tenable-vpr-mcp
Security Penetration Testing
Sabastiaz
A
license
A
quality
D
maintenance
MCP server for Tenable.io/One Vulnerability Management that provides read-only tools for querying scans, assets, plugins, and vulnerabilities, plus specialized reporting tools for VPR re-prioritization, CISA KEV/EPSS exposure, and scan delta comparisons.
Updated 3 months ago (2026-08-06 00:33 UTC)
11
3
MIT
tenable-activity-mcp
Security Monitoring
brendanong95
A
license
A
quality
D
maintenance
Enables querying and analyzing Tenable Vulnerability Management audit logs, including activity summaries, API key usage, and anomaly detection through MCP tools.
Updated 3 months ago (2026-08-19 16:34 UTC)
6
MIT

Tenable Identity Exposure MCP Server

Credentials are never stored in this repository

Tools

Read-only by default

Time windows, profiles, and token budget

Configuration

Install & run

Reaching a network transport from another host

Tests

Running with uv / uvx (alternative to a manual venv)

Claude Desktop / Claude Code config

With uv (alternative)

Docker

Example prompts

Notes

Available Tools

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

tie-mcp-server

Tenable Identity Exposure MCP

tenable-vpr-mcp

tenable-activity-mcp