tenable-patch-management-logs-mcp

Overview Schema Source Related Servers Discussions Admin

build_timeline

Read-onlyIdempotent

Merge server and client logs into one chronological timeline to trace what happened before and after an incident. Interleaves entries by timestamp, removes duplicates, and collapses repeats for clearer root-cause analysis.

Instructions

Merge all logs into one chronological sequence - what happened before and after.

Useful for "what led up to this failure": server and client logs are interleaved by timestamp, duplicates across logs removed, and consecutive repeats collapsed (repeats). When there are more rows than limit, WARN and above are always kept and the rest are sampled evenly (sampled).

Args: around: Centre the window on this time (ISO, or relative like 2h). minutes_before: Minutes before around (default 15). minutes_after: Minutes after around (default 15). since: Window start when not using around. Default: the last 60 minutes of logs. until: Window end when not using around. source: Source name; omit for all sources. device: Only this device. role: "server", "client" or "setup". files: Log names or globs. min_severity: INFO (default), WARN, ERROR; DEBUG to include debug lines. keyword: Only entries containing this text. include_noise: Include known platform noise. collapse_repeats: Merge consecutive identical rows (default true). limit: Rows to return (10-1000).

Returns: rows in time order, each with time, device, severity, log, component, message and at (file:line).

Input Schema

TableJSON Schema

Name	Required	Default
`role`	No
`files`	No
`limit`	No
`since`	No
`until`	No
`around`	No
`device`	No
`source`	No
`keyword`	No
`min_severity`	No	INFO
`include_noise`	No
`minutes_after`	No
`minutes_before`	No
`collapse_repeats`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses important behavior: duplicate removal, consecutive repeat collapsing, and the overflow policy where WARN and above are kept while the rest are sampled. It also documents the return row structure, giving the agent a clear model of what the tool does.

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 well-structured with a front-loaded purpose, behavior notes, a compact Args list, and a short Returns section. Every sentence earns its place; despite covering 14 parameters, it remains readable and free of redundancy.

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 14-parameter tool with zero schema descriptions, the description covers purpose, filtering options, defaults, behavioral edge cases (limit overflow), and return fields. Nothing essential for correctly invoking the tool appears to be missing.

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%, so the description carries full responsibility for parameter meaning. The 'Args' section explains all 14 parameters, including defaults for minutes_before, minutes_after, min_severity, collapse_repeats, and the limit range, making every parameter actionable without schema descriptions.

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 opens with a specific action and resource: 'Merge all logs into one chronological sequence - what happened before and after.' It also ties the tool to a concrete use case ('what led up to this failure') and distinguishes it from sibling log tools by emphasizing interleaving server/client logs by timestamp.

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 clearly states when the tool is useful: reconstructing what led up to a failure by merging and time-ordering logs. It does not explicitly name alternatives or state when not to use it, but the scenario is concrete enough for an agent to select it appropriately.

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

Deploy Server