tenable-activity-mcp

list_activity_events

Retrieve Tenable audit-log events for a date range with optional actor and action filters. Pagination is handled automatically, and sensitive credential fields are redacted for safe analysis.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`action`	No
`date_to`	Yes
`actor_id`	No
`date_from`	Yes
`next_token`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so exceptionally well. It discloses internal pagination with a 20-page/100k-event cap, resume behavior via next_token, normalization of events, access-type tagging, and redaction of credential-looking fields. This is far beyond what a minimal description would provide.

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 yet well-structured: purpose first, then behavioral caveats, then parameter breakdown, then return structure. Every sentence adds value, and the length is justified by the number of parameters and the pagination/redaction behaviors that need explanation.

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 6-parameter tool with no annotations, the description covers use case, filtering, pagination limits, resume semantics, data normalization, redaction, and return shape. The optional filters and cap behavior are fully explained, leaving no critical gap for an agent attempting to invoke the tool correctly.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates completely by explaining every parameter: date format and inclusivity, optional filters with their eq semantics, the exact action example, limit range, and the opaque next_token cursor. An agent can correctly populate all six arguments without needing extra documentation.

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 begins with a specific verb ('List') and resource ('Tenable audit-log events'), and states the scope ('for a date range') with optional filters. This clearly distinguishes it from sibling tools like summarize_activity and detect_anomalies, so an agent knows exactly what this tool retrieves.

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 makes the core use case clear: retrieve audit-log events within a date range, optionally filtered by actor or action. It does not explicitly name sibling alternatives or provide when-not-to-use guidance, but the event-listing purpose is unambiguous and the filter details help an agent choose appropriately.

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

Deploy Server