Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tenable-mcp list all assets with hostname containing prod"
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.
A Model Context Protocol (MCP) server for Tenable Vulnerability Management and Tenable Security Center.
Exposes Tenable security operations as MCP tools for AI-powered security workflows.
uvx tenable-mcpRelated MCP server: GhostMap v2
Variable | Required | Default | Description |
| Yes | — | Tenable API access key |
| Yes | — | Tenable API secret key |
| No |
| Tenable.io base URL |
| No | — | Tenable.sc URL (enables SC support) |
| No |
| Set to |
| No |
| Connection timeout in seconds |
| No |
| Default page size for paginated requests |
{
"mcpServers": {
"tenable": {
"command": "uvx",
"args": ["tenable-mcp"],
"env": {
"TENABLE_ACCESS_KEY": "your-access-key",
"TENABLE_SECRET_KEY": "your-secret-key"
}
}
}
}{
"mcpServers": {
"tenable": {
"command": "uv",
"args": ["run", "tenable-mcp"],
"env": {
"TENABLE_ACCESS_KEY": "your-access-key",
"TENABLE_SECRET_KEY": "your-secret-key"
}
}
}
}Tool | Description |
| List assets with filters (hostname, IP, network, tracking method) |
| Get detailed information for a specific asset by UUID |
| Get vulnerabilities for a specific asset |
Tool | Description |
| Search vulnerabilities across all assets with extensive filters |
| Get details for a vulnerability finding or plugin |
| List vulnerability findings from the workbench |
Tool | Description |
| List configured scans |
| Get scan details |
| Launch a scan (requires |
| Export scan results (nessus, csv, html, pdf, db) |
Tool | Description |
| Search for plugins by name, family, CVE, severity |
| Get detailed plugin information including CVSS and CVE |
Tool | Description |
| List configured tags with category/value filters |
Tenable Vulnerability Management (Tenable.io) — Full support
Tenable Security Center (Tenable.sc) — Partial support (requires TENABLE_SC_URL)
Tenable Nessus — Not directly supported (use Tenable.io with agents)
# Clone and install
git clone https://github.com/your-org/tenable-mcp.git
cd tenable-mcp
uv sync
# Run quality checks
uv run ruff check .
uv run ruff format --check .
uv run pyright .
uv run pytestMIT
Export a scan and save it to a specified file path.
Use this when you need to control where the exported file is saved, rather than using a temporary location.
Example: Input: { "scan_id": 123, "output_path": "/home/user/weekly_scan.csv", "format": "csv" } Output: {"file_path": "/home/user/weekly_scan.csv", "status": "completed"}
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | nessus | |
| scan_id | Yes | ||
| chapters | No | ||
| password | No | ||
| output_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description relies on readOnlyHint annotation for safety profile, adding no extra behavioral context beyond the export action. No details on file overwrite, permissions, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three sentences plus a clear example. No redundant information; front-loaded with core purpose and when-to-use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides enough context for typical use with example output, but lacks explanation of optional parameters (chapters, password) and detailed behavior on failure. Good for a download tool with annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description explains scan_id, output_path, and format via example, but does not cover chapters or password parameters. Adds some meaning beyond schema but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool exports a scan and saves to a specified file path. Distinguishes from sibling 'tenable_export_scan' by focusing on user-controlled output location vs temporary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when you need to control where the exported file is saved, rather than using a temporary location,' providing clear guidance on when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export scan results.
The export is downloaded as a file. Supported formats: nessus, csv, html, pdf, db.
Example: Input: {"scan_id": 123, "format": "csv"} Output: {"file_id": "...", "format": "csv", "status": "ready"}
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | nessus | |
| scan_id | Yes | ||
| chapters | No | ||
| password | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares readOnlyHint=true, but the description describes an export that creates a file, implying a write operation. This is a contradiction. Additionally, the description does not disclose whether the export is asynchronous, if it modifies state, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a clear first sentence and an illustrative example. However, it could be more structured by separating key details from the example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and limited parameter description, the description omits important context such as whether the export is asynchronous, how to retrieve the file (via sibling tool), or any limitations. The behavioral contradiction further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only provides an example with scan_id and format, but does not explain the chapters or password parameters. The example uses format 'csv' while the schema default is 'nessus', which could confuse agents. The description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports scan results and lists supported formats, with an example input/output. However, it does not explicitly differentiate from the sibling tool tenable_download_scan_export, leaving some ambiguity about whether this initiates an export or directly provides a download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tenable_download_scan_export. There is no mention of prerequisites, when not to use it, or how it fits into a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific asset.
Example: Input: {"uuid": "123e4567-e89b-12d3-a456-426614174000"} Output: {"id": "...", "hostname": "server01", "ipv4": "10.0.0.1", ...}
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds an example output showing fields like id, hostname, and ipv4, which provides some behavioral context. However, it does not disclose potential errors, permissions, or rate limits, so it adds only moderate value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence followed by an example. Every word is functional, with no unnecessary phrasing. It is well-structured and easily digestible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter) and no output schema, the description covers the essential purpose and provides an example output. It lacks information on error handling or behavior when the asset is not found, but it is reasonably complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It provides an example showing the uuid parameter with a sample value, which hints at its purpose but does not explicitly explain that it is the asset identifier. For a single parameter, this is adequate but not fully clarifying.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific asset. The verb 'Get' and resource 'detailed information about a specific asset' are precise. Additionally, the tool name combined with sibling tools like tenable_list_assets implies it targets a single asset, distinguishing it effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as tenable_list_assets or tenable_get_asset_vulnerabilities. The description lacks usage context, prerequisites, or exclusions, relying solely on the tool name and parameters to imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get vulnerabilities for a specific asset.
Example: Input: {"uuid": "123e4567-...", "severity": "critical"} Output: {"vulnerabilities": [...], "total": 5}
| Name | Required | Description | Default |
|---|---|---|---|
| cve | No | ||
| uuid | Yes | ||
| limit | No | ||
| severity | No | ||
| plugin_id | No | ||
| exploit_available | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds output structure (vulnerabilities array with total) but omits important behaviors like pagination via limit parameter or filtering effects. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: two sentences plus an example. The first sentence front-loads the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and numerous sibling tools, the description lacks completeness. It does not explain the meaning of all parameters, return format details beyond basic, or differentiation from similar tools like tenable_list_findings or tenable_search_vulnerabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only partially clarifies uuid and severity via example, leaving cve, limit, plugin_id, and exploit_available unexplained. Inadequate for a tool with 6 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'vulnerabilities for a specific asset'. It distinguishes from sibling tools like tenable_list_findings which might be broader, and tenable_get_vulnerability_details which targets a single vulnerability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives like tenable_search_vulnerabilities or tenable_list_findings. The example implies usage but does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific plugin.
Includes CVSS scores, CVE references, solution, and exploit information.
Example: Input: {"plugin_id": 19506} Output: { "id": 19506, "name": "Apache Log4j ...", "cvss_base_score": 10.0, "cve": ["CVE-2021-44228"], ... }
| Name | Required | Description | Default |
|---|---|---|---|
| plugin_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully aligns with the readOnlyHint annotation, describing a read operation that returns detailed plugin information. It discloses the nature of the output without contradicting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two informative sentences and an example. It is front-loaded with the primary action and avoids unnecessary words. The truncated example is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description adequately explains the output contents (CVSS, CVE, solution, exploit). Combined with the read-only annotation, an agent has sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single required parameter plugin_id. The description provides an example but does not explain what the parameter represents or its format. While the parameter is straightforward, the description should clarify its meaning given no schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific plugin' and lists included elements (CVSS scores, CVE references, solution, exploit). This distinguishes it from sibling tools like tenable_search_plugins, which are for searching rather than retrieving details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific plugin ID, but does not explicitly state when to use this tool vs alternatives like search_plugins. No exclusion or alternative guidance is provided, so the agent must infer from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific scan.
Example: Input: {"scan_id": 123} Output: {"id": 123, "name": "Weekly Scan", "status": "completed", ...}
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation but adds no additional behavioral context beyond the example output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a helpful example. No wasted words, though the example could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description gives a general idea but lacks detail on what 'detailed information' includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description for scan_id). The description only mentions scan_id in the example without explaining its meaning or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific scan,' distinguishing it from sibling tools that list or launch scans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example but no explicit guidance on when to use this tool versus alternatives like tenable_list_scans or tenable_launch_scan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific vulnerability or plugin.
Provide either vuln_id (finding UUID) or plugin_id (Nessus plugin ID).
Example: Input: {"plugin_id": 19506} Output: {"id": 19506, "name": "Apache Log4j ...", "cve": ["CVE-2021-44228"], ...}
| Name | Required | Description | Default |
|---|---|---|---|
| vuln_id | No | ||
| plugin_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the 'readOnlyHint' annotation, indicating it is a read operation. The example output adds context about the return structure, but no additional behavioral traits (e.g., rate limits, error handling) are disclosed beyond what annotations already cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with the purpose stated in the first sentence. The parameter guidance and example are efficient, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with two optional parameters and no output schema, the description covers purpose and parameter choice but lacks details on return value structure beyond a partial example. It fails to mention what happens if both parameters are provided or if neither is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining that 'vuln_id' is a finding UUID and 'plugin_id' is a Nessus plugin ID. This adds meaning beyond the schema's type definitions. However, it does not clarify that both parameters are optional, which could lead to ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get detailed information about a specific vulnerability or plugin.' It clearly identifies the action and resource, and distinguishes from sibling tools that might perform bulk searches. However, it does not explicitly differentiate from the sibling 'tenable_get_plugin_details', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives parameter guidance ('Provide either vuln_id or plugin_id'), but does not specify when to use this tool versus alternatives like 'tenable_search_vulnerabilities' or 'tenable_get_plugin_details'. No when/when-not conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check connectivity and health of the Tenable.io service.
Verifies that the configured credentials are valid and the API is reachable. Returns server properties and status.
Example: Input: {} Output: { "status": "healthy", "server": {"version": "...", "uuid": "..."}, "license": {...} }
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds that it verifies credentials and API reachability, returning server properties. No contradictions. The behavioral context is adequately described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, includes an example, and is well-structured. It could be slightly more terse, but it effectively communicates the essential information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates with an example output showing expected fields. For a simple health check, this is complete enough to guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage). The description adds an example that shows the output structure, providing meaning beyond the empty schema. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks connectivity and health of the Tenable.io service, verifying credentials and API reachability. This distinguishes it from sibling tools that perform specific operations like scanning or asset management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: to check connectivity and health. While it doesn't mention when not to use it or alternatives, the use case is unambiguous and self-contained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch a scan.
WARNING: This is a state-changing operation. Set confirm: true to proceed.
Example: Input: {"scan_id": 123, "confirm": true} Output: {"scan_uuid": "...", "status": "launched"}
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| scan_id | Yes | ||
| targets | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds the 'confirm: true' requirement beyond the annotations' destructiveHint. It also provides an example output, clarifying the mutation behavior. Could mention idempotency or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded with purpose, includes essential warning and example. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and behavioral warning, but lacks parameter descriptions for scan_id and targets, and doesn't fully describe output for a 3-parameter tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description only clarifies 'confirm' via warning and example. scan_id is shown but not explained, and targets is omitted entirely. Insufficient for effective invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Launch a scan' which is a specific verb+resource. It distinguishes from sibling tools that perform read, export, download, or list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a warning about state-changing and requiring confirm, implying caution. However, no explicit when-to-use or alternatives compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List assets from Tenable Vulnerability Management.
Returns a paginated list of assets with optional filters for hostname, IP address, tracking method, and network.
Example: Input: {"hostname": "web-server", "limit": 10} Output: {"assets": [...], "total": 10}
| Name | Required | Description | Default |
|---|---|---|---|
| ipv4 | No | ||
| ipv6 | No | ||
| limit | No | ||
| hostname | No | ||
| network_id | No | ||
| tracking_method | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly identifies the tool as read-only (consistent with readOnlyHint annotation) and mentions pagination. However, it does not detail pagination behavior (e.g., default limit, max limit) or error handling, which would add value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear sentences and a helpful example. Every sentence adds value without redundancy. It is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no schema descriptions, and no output schema, the description is adequate but incomplete. It provides an example and mentions filters but lacks details on parameter formats, valid values for tracking_method or network_id, and the structure of the response beyond a basic example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description partially explains parameters by listing hostname, IP address, tracking method, and network as filters. However, it does not describe all six parameters (e.g., ipv4 vs ipv6 are not distinguished, limit is only implied in example). With 0% schema description coverage, the description should compensate more fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists assets from Tenable Vulnerability Management, with a specific verb and resource. It distinguishes from siblings like tenable_get_asset (single asset) and tenable_list_scans by focusing on assets. The mention of optional filters further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for usage: listing assets with optional filters and pagination. An example is given. However, it does not explicitly state when to use this tool vs alternatives like tenable_get_asset (for a single asset) or tenable_search_vulnerabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List vulnerability findings using the Tenable exports API.
Uses the modern exports.vulns() API for the most current view of vulnerabilities across your environment.
Example: Input: {"severity": "high", "state": "OPEN", "limit": 100} Output: {"findings": [...], "total": 45}
| Name | Required | Description | Default |
|---|---|---|---|
| cve | No | ||
| tags | No | ||
| limit | No | ||
| since | No | ||
| state | No | ||
| severity | No | ||
| plugin_id | No | ||
| exploit_available | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation indicates a safe read operation, which the description's 'list' verb aligns with. The description adds the API method name (exports.vulns()) but does not disclose additional behavioral traits like data freshness, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus an example) and front-loaded with the key action. Every sentence adds value, though the example could be considered part of the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description is too brief. It lacks explanations of filtering, pagination, return structure beyond the partial example, and how to interpret results. The context signals indicate high complexity that the description does not address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameter descriptions are provided in the text. The example hints at severity, state, and limit, but with 0% schema coverage, the description fails to explain the meaning, valid values, or effect of the 8 parameters beyond their names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists vulnerability findings using the Tenable exports API. It includes an example and mentions the modern API. However, it does not explicitly differentiate from sibling tools like tenable_get_vulnerability_details or tenable_search_vulnerabilities, which could overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention when it is appropriate to use, when not to use, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured scans.
Returns a list of all scans (or filtered by folder/name).
Example: Input: {"limit": 20} Output: {"scans": [...], "total": 5}
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| limit | No | ||
| folder_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm read-only. Description adds an example output structure and mentions filtering. No contradictions. Details beyond annotations are limited but sufficient for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus an example. Front-loaded purpose, no wasted words. The example is helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 optional parameters and no output schema, the description is adequate but lacks details on output structure beyond the example. Does not address pagination or limits behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description explains name and folder_id filters but not the limit parameter. The example shows limit usage but without explanation. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists configured scans and can filter by folder or name. It distinguishes from siblings like tenable_get_scan which retrieves a single scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing scans with optional filters but does not explicitly compare to alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured tags.
Tags are key-value pairs used to organize and filter assets (e.g., 'Location:US-East', 'Environment:Production').
Example: Input: {"category": "Location", "limit": 20} Output: {"tags": [...], "total": 5}
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| value | No | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the readOnlyHint annotation. It does not disclose pagination, rate limits, or whether the tool returns all tags by default. The example shows an output format but lacks details on practical limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence and an example. It front-loads the purpose. Every part adds value, though the example could be integrated more succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and lack of output schema, the description covers the core concept and example usage. It is adequate but could be improved by explaining default behavior, maximum limit, or the effect of the 'value' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by illustrating the 'category' and 'limit' parameters in an example. However, the 'value' parameter is not explained, and the schema defines all parameters as optional with no defaults beyond null, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List configured tags' and explains that tags are key-value pairs for organizing assets. This verb+resource construction distinguishes it from sibling tools like tenable_list_assets or tenable_list_scans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when to prefer list_tags over other list tools, nor does it specify filters or constraints on usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Tenable plugins by name, family, CVE, or other criteria.
Example: Input: {"query": "Apache Log4j", "cve": "CVE-2021-44228", "limit": 10} Output: {"plugins": [...], "total": 3}
| Name | Required | Description | Default |
|---|---|---|---|
| cve | No | ||
| limit | No | ||
| query | No | ||
| family | No | ||
| severity | No | ||
| plugin_id | No | ||
| plugin_type | No | ||
| exploit_available | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the agent knows it's a read operation. The description adds that it searches based on criteria and returns a list with total count, but does not disclose pagination behavior, error handling, or rate limits. With annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence defining the tool and a practical example. Every sentence adds value, and the example is front-loaded. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 optional parameters, no output schema, and annotations only provide readOnlyHint, the description is too sparse. It does not explain how multiple criteria combine, result ordering, or behavior when no results. The example helps but is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only mentions a few parameters (name, family, CVE) and omits others like severity, plugin_id, exploit_available. The example shows query, cve, limit but not all. Insufficient for an 8-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for Tenable plugins by name, family, CVE, or other criteria. The example reinforces the purpose. It distinguishes from siblings like tenable_get_plugin_details (single plugin) and tenable_list_findings (different scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as tenable_get_plugin_details or tenable_search_vulnerabilities. The description only provides an example but no context for when it is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for vulnerabilities across all assets.
Uses the Tenable exports API with extensive filtering for severity, CVE, exploit availability, port, protocol, tags, and time range.
Example: Input: { "severity": "critical", "exploit_available": true, "since": 1700000000, "limit": 50 } Output: {"vulnerabilities": [...], "total": 12}
| Name | Required | Description | Default |
|---|---|---|---|
| cve | No | ||
| ipv4 | No | ||
| port | No | ||
| tags | No | ||
| limit | No | ||
| since | No | ||
| state | No | ||
| hostname | No | ||
| protocol | No | ||
| severity | No | ||
| plugin_id | No | ||
| exploit_maturity | No | ||
| threat_intensity | No | ||
| exploit_available | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's 'Search' aligns. It adds that it uses the 'Tenable exports API' and shows an output format, but doesn't disclose potential side effects, rate limits, or pagination behavior beyond the example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-line summary, a note on the API, and an illustrative example. No unnecessary text, but the structure could be improved by grouping parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters and no output schema, the description provides an example output but does not explain the complete response structure, pagination, or the effect of the 'limit' parameter. It is adequate for simple use but incomplete for complex queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists some filtering parameters (severity, CVE, exploit availability, port, protocol, tags, time range) but covers only about 7 out of 14 parameters. The example provides concrete usage but the description does not explain formats, allowed values, or behavior for undocumented parameters like ipv4 or hostname. With 0% schema coverage, more detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for vulnerabilities across all assets', specifying the verb (search) and resource (vulnerabilities). It distinguishes from siblings like tenable_get_asset_vulnerabilities by emphasizing 'across all assets'. However, it could be more explicit about the scope compared to other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'extensive filtering' and provides an example, implying usage for broad vulnerability searches. However, it does not explicitly say when to use this tool over alternatives like tenable_get_asset_vulnerabilities or tenable_list_findings, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a Web Application Scanning (WAS) report.
Retrieves the detailed report for a specific WAS scan.
Example: Input: {"scan_uuid": "123e4567-e89b-12d3-a456-426614174000"} Output: {"report": {...}, "scan_uuid": "..."}
| Name | Required | Description | Default |
|---|---|---|---|
| scan_uuid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description's 'download' and 'retrieves' are consistent. Description adds example output but no additional behavioral details like format or size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief with two sentences and an example. No fluff, but the example could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but example shows structure. Missing details on report format, file download semantics, error conditions, or authentication requirements beyond annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, scan_uuid, has no description in schema (0% coverage) and the tool description does not explain its meaning or format beyond a placeholder example. Agent lacks guidance on how to obtain or format the UUID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a WAS report, using specific verb 'download' and resource 'Web Application Scanning report'. It distinguishes from siblings like tenable_download_scan_export by specifying WAS context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like tenable_was_export or tenable_download_scan_export. The example implies usage but doesn't explain selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export Web Application Scanning (WAS) findings.
Retrieves web application vulnerability findings with optional date and status filters.
Example: Input: {"scan_status": "completed", "scan_started_after": "2024/01/01"} Output: {"was_findings": [...], "total": 5}
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scan_status | No | ||
| scan_started_after | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds context about filtering and output format, but does not disclose additional behavioral traits such as rate limits, pagination behavior, or authentication requirements beyond the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences and an example. Each sentence adds value—purpose, filtering options, and an illustrative example. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 optional parameters, the description provides an example output shape (array and total) but does not detail individual finding fields. The limit parameter is not explained. Adequate for basic use but missing details for advanced usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for parameters. The description clarifies that scan_status and scan_started_after are optional filters, but does not explain the limit parameter. Partially compensates for the missing schema descriptions but leaves one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Export Web Application Scanning (WAS) findings' and 'Retrieves web application vulnerability findings', specifying the resource and action. Distinguishes from siblings like tenable_download_scan_export by focusing on WAS findings output as JSON.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an example and mentions optional date/status filters, but does not explicitly state when to use this tool versus alternatives like tenable_search_vulnerabilities or tenable_export_scan. Usage is implied by the tool name and description, but lacks explicit guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0tenable_download_scan_exporttenable_export_scantenable_get_assettenable_get_asset_vulnerabilitiestenable_get_plugin_detailstenable_get_scantenable_get_vulnerability_detailstenable_health_checktenable_launch_scantenable_list_assetstenable_list_findingstenable_list_scanstenable_list_tagstenable_search_pluginstenable_search_vulnerabilitiestenable_was_download_reporttenable_was_exportThere is notable overlap between tenable_list_findings and tenable_search_vulnerabilities (both list vulnerabilities using exports API) and between tenable_get_vulnerability_details and tenable_get_plugin_details (get_vuln_details also accepts plugin_id). While descriptions help, agents may struggle to choose the correct tool for vulnerability-related queries.
All tools follow a consistent tenable_<verb>_<noun> pattern using snake_case. Verbs are distinct and the pattern is predictable, making it easy for an agent to infer tool functionality from names.
17 tools cover the key areas of a vulnerability management platform (assets, scans, vulnerabilities, plugins, tags, health, and WAS) without being overwhelming. The count feels appropriate for the domain.
The tool set covers most read and export operations comprehensively, including search, details, and list endpoints. However, it lacks create/update/delete for many resources (e.g., assets, tags, scans) and missing scan lifecycle operations like stop/pause, which are minor gaps for a read-centric server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Let AI agents query data and act across all your business apps via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nguyenthdat/tenable-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
