Skip to main content
Glama
brendanong95

tenable-activity-mcp

by brendanong95

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_activity_eventsA

List Tenable audit-log events for a date range, with optional filters.

Pagination is handled internally (the next cursor is followed automatically) up to a safety cap of 20 pages / 100k events per call; if the cap is hit, pagination.next_token is returned so the next call resumes exactly where this one stopped. Every event is normalised, tagged with an access type (API key vs UI session), and has credential-looking field values redacted to their last 4 characters.

Args: date_from: Start of the window, ISO-8601 (e.g. "2024-01-01" or "2024-01-01T00:00:00Z"). Inclusive. date_to: End of the window, ISO-8601. Inclusive. actor_id: Optional actor UUID to filter on (actor_id.eq). action: Optional exact action name, e.g. "user.create" (action.eq). limit: Page size sent to the API (1-5000). next_token: Opaque cursor from a previous call, to resume pagination.

Returns: A dict with events (classified, redacted), a summary rollup of those events, and a pagination block.

summarize_activityA

Summarise all audit-log activity in a window (counts computed in Python).

Returns event counts by actor, by action, by CRUD type and by access type, plus failure and anonymous rates - all pre-computed. Use these numbers directly; do not re-derive them from raw events.

Args: date_from: Start of the window, ISO-8601. Inclusive. date_to: End of the window, ISO-8601. Inclusive.

Returns: A dict with a summary block (total_events, by_actor, by_action, by_crud, by_access_type, failure_rate_pct, top_failed_actions) and a pagination block describing coverage.

get_api_key_usageA

Report API-key-driven activity per actor (UI/session activity excluded).

Events are classified as API-key driven using the audit event's access/auth-method field, falling back to user-agent shape (scripted client vs browser). Each actor gets an action breakdown, distinct source IPs, and first/last seen timestamps - all pre-aggregated.

Args: actor_id: Optional actor UUID. Omit to cover every actor with API-key activity in the window. date_from: Start of the window, ISO-8601. Defaults to 30 days ago. date_to: End of the window, ISO-8601. Defaults to now.

Returns: A dict with actors (per-actor API-key usage profiles), an access_type_totals breakdown for context, and coverage metadata.

detect_anomaliesA

Compare a window against each actor's stored baseline and flag outliers.

Checks run: previously unseen actor, event volume above SPIKE_MULTIPLIER x the actor's historical daily average, source IPs absent from the baseline lookback, failed-event bursts, sustained high failure rate, off-hours activity spikes, and never-before-seen action types. Every finding includes the observed value, the threshold crossed, and a reasoning sentence.

Baselines live in the local SQLite state file and are refreshed from the period immediately preceding the window when they are stale. Events in the analysed window itself are not folded into the baseline, so re-running the same window yields the same findings.

Args: date_from: Start of the window under investigation, ISO-8601. date_to: End of the window under investigation, ISO-8601. baseline_days: Days of history preceding the window to baseline against.

Returns: A dict with findings (severity-ordered, each with evidence and reasoning), findings_by_type/findings_by_severity counts, and the active thresholds.

get_actor_profileA

Full historical view of one actor: roles, actions, access types, IPs.

Combines a fresh audit-log fetch for the actor with everything previously persisted in the local state database, so IPs and actions seen in earlier sessions still show up. The Tenable role is resolved on a best-effort basis from the user directory and is omitted when the API keys cannot list users.

Args: actor_id: The actor UUID (as it appears in actor.id on events). lookback_days: How far back to fetch fresh events for this actor.

Returns: A dict with identity, recent_activity (rollup over the lookback window), lifetime (accumulated state: all IPs, all actions, all access types, first/last seen) and pagination.

check_permission_prereqsA

Verify the configured API keys can actually read the audit log.

Makes one minimal audit-log request and reports pass/fail with a plain explanation and remediation steps. Run this first when another tool returns an authentication or permission error. No secret material is echoed - the access key is shown with only its last 4 characters.

Returns: A dict with ok, a human-readable message, remediation when failing, plus configuration and local-state diagnostics.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.7/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a clearly different concern: raw event listing, summary rollups, API-key-specific usage, anomaly detection, actor profiling, and prerequisite checks. Even the two aggregation tools (summarize_activity and get_api_key_usage) are separated by access-type scope, and their descriptions reinforce the distinction.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: list_activity_events, summarize_activity, get_api_key_usage, detect_anomalies, get_actor_profile, check_permission_prereqs. The verbs clearly signal the action and the objects clearly signal the resource or concern, making the set predictable and easy to navigate.

Tool Count5/5

Six tools is well-scoped for an audit-log activity server: two raw/aggregate views, two analysis-focused tools, one deep-dive tool, and one operational prerequisite check. Each tool earns its place without redundancy or bloat.

Completeness5/5

The tool surface covers the full audit-monitoring lifecycle: listing raw events, summarizing them, isolating API-key usage, detecting anomalies, profiling individual actors, and verifying access prerequisites. The automatic pagination and baseline handling close potential dead ends, so an agent can move from raw data to insight without missing critical operations.

Maintenance

ActivitySlowing
ResponsivenessNo issues