What can you do with this server?

This server lets AI assistants interact with Tenable Nessus to manage vulnerability scans and analyze findings via MCP. * List scan templates to see available Nessus scan types * Start vulnerability scans against IPs or hostnames using basic network, web app, or compliance scan types * Check scan status for running scans * Get scan results from completed scans * List all scans and their statuses * Get detailed vulnerability information by CVE (mock mode) or Nessus plugin ID (real mode) * Search vulnerabilities by keyword, optionally scoped to a specific scan in real mode * Runs in mock mode without credentials or real mode using Nessus API keys * Supports self-signed Nessus certificates with an explicit opt-in flag

Which integrations are available for this server?

Required runtime environment to execute the MCP server, supporting the server's execution for vulnerability scanning functionality. Development language used for building the MCP server, providing type safety for the Nessus vulnerability scanning integration.

How do I use Nessus MCP Server?

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., "@Nessus MCP Server start a vulnerability scan on 192.168.1.0/24" 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.

en es ja ko zh

Nessus MCP Server

by Cyreslab-AI

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Nessus MCP Server

A Model Context Protocol (MCP) server for interacting with the Tenable Nessus vulnerability scanner. This server allows AI assistants to perform vulnerability scanning and analysis through the MCP protocol.

It talks to a real Nessus instance over its REST API using API-key authentication. If no NESSUS_URL/NESSUS_ACCESS_KEY/NESSUS_SECRET_KEY are set, it falls back to a self-contained mock mode for local development and testing.

Features

Vulnerability Scanning: Start and monitor vulnerability scans against specified targets
Scan Management: List, track, and retrieve results from vulnerability scans
Vulnerability Analysis: Search for and get detailed information about specific vulnerabilities
Mock Mode: Fully functional mock mode for testing without a Nessus API key

Related MCP server: mcp-nutanix

Tools

The server provides the following tools:

Tool Name	Description
`list_scan_templates`	List available Nessus scan templates
`start_scan`	Start a new vulnerability scan against a target
`get_scan_status`	Check the status of a running scan
`get_scan_results`	Get the results of a completed scan
`list_scans`	List all scans and their status
`get_vulnerability_details`	Get detailed information about a specific vulnerability
`search_vulnerabilities`	Search for vulnerabilities by keyword

Installation

Prerequisites

Node.js 20 or higher
TypeScript (for development)

Building from Source

Clone the repository:

git clone https://github.com/Cyreslab-AI/nessus-mcp-server.git
cd nessus-mcp-server

Install dependencies:
```
npm install
```
Build the server:
```
npm run build
```

Usage

Running in Mock Mode

By default, the server runs in mock mode, which doesn't require a Nessus API key:

node build/index.js

Running with a real Nessus instance

To connect to a real Nessus instance, set the following environment variables:

NESSUS_URL=https://your-nessus-instance:8834
NESSUS_ACCESS_KEY=your-access-key
NESSUS_SECRET_KEY=your-secret-key

The server is switched into real mode as soon as all three of these are set; otherwise it runs in mock mode.

Then run the server:

node build/index.js

Generating an API key pair

In the Nessus web UI: Settings > My Account > API Keys > Generate. Nessus shows the access key and secret key only once at generation time, so store them somewhere safe (e.g. a secrets manager or your MCP client's env config) - Nessus itself cannot show them to you again.

Requests authenticate with the X-ApiKeys: accessKey=<key>; secretKey=<key> HTTP header on every call. There is no separate login/session step, and no cookie or token to refresh.

Self-signed certificates

Nessus is very commonly deployed with a self-signed TLS certificate. By default this server verifies certificates strictly and will fail closed against a self-signed instance. To explicitly opt in to skipping certificate verification (e.g. for an internal instance you trust), set:

NESSUS_ALLOW_SELF_SIGNED=true

Leave this unset (or false) whenever the instance has a certificate issued by a trusted CA. The server logs a warning to stderr on startup whenever this is enabled.

Design notes on the real-mode mapping

A few of this server's tools have no exact 1:1 equivalent in the Nessus REST API, so the following judgment calls were made:

start_scan: scan_type (basic-network-scan / web-app-scan / compliance-scan) is a logical name, not a Nessus template UUID (those are instance-specific and returned by GET /editor/scan/templates). This server resolves the logical name to a template by matching known template name values first, falling back to a fuzzy match against the template name/title. start_scan then creates the scan (POST /scans) and immediately launches it (POST /scans/{id}/launch), since the tool is named "start", not "create".
get_scan_results: real scan results are aggregated per-plugin across the whole scan (from GET /scans/{id}'s vulnerabilities summary), not the fully-enriched, per-vulnerability records the mock data returns. Fetching full CVSS/description/remediation text for every plugin would mean one extra Nessus API call per finding, which does not scale for scans with many findings. Use get_vulnerability_details with a specific plugin_id from the results to drill into full detail for one finding.
get_vulnerability_details: in mock mode this takes a CVE id. Against a real Nessus instance it must be a numeric Nessus plugin ID instead (e.g. 156327), because the on-prem Nessus REST API has no endpoint that resolves an arbitrary CVE or keyword to a plugin - only GET /plugins/plugin/{id} (lookup by numeric plugin ID) exists. A CVE-shaped input in real mode returns a clear, documented error rather than silently failing.
search_vulnerabilities: Nessus has no single "search all vulnerabilities" endpoint - findings only exist in the context of a scan's results. In real mode this tool accepts an optional scan_id to scope the search to one scan; without it, the search covers the most recently updated completed scans (capped at 10, to bound the number of API calls on instances with many scans). This is a deliberate scoping decision, documented on the tool description itself.

Using with Claude for Desktop

To use this server with Claude for Desktop:

Edit your Claude for Desktop configuration file:
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the server configuration:

{
  "mcpServers": {
    "nessus": {
      "command": "node",
      "args": ["/path/to/nessus-mcp-server/build/index.js"],
      "env": {
        "NESSUS_URL": "https://your-nessus-instance:8834",
        "NESSUS_ACCESS_KEY": "your-access-key",
        "NESSUS_SECRET_KEY": "your-secret-key",
        "NESSUS_ALLOW_SELF_SIGNED": "false"
      }
    }
  }
}

For mock mode, you can omit the env section.

Example Interactions

Starting a Scan

start_scan:
  target: 192.168.1.1
  scan_type: basic-network-scan

Getting Scan Results

get_scan_results:
  scan_id: scan-1234567890

Searching for Vulnerabilities

search_vulnerabilities:
  keyword: log4j

Against a real Nessus instance, optionally scope the search to one scan:

search_vulnerabilities:
  keyword: log4j
  scan_id: 42

Development

Project Structure

src/index.ts: Main server entry point
src/nessus-api.ts: Nessus API client with mock fallback
src/mock-data.ts: Mock vulnerability data for testing
src/tools/: Tool implementations
src/utils/: Utility functions

Adding New Tools

Define the tool schema and handler in the appropriate file in src/tools/
Import and register the tool in src/index.ts

Verification status

Real-mode requests are implemented directly against the documented Tenable Nessus REST API contract (endpoints, request bodies, and response shapes). They have been verified by:

A clean TypeScript build (npm run build).
Exercising every tool over stdio in real mode against an unreachable NESSUS_URL (e.g. https://localhost:1), confirming the server starts, accepts requests, and returns a clean isError response with a descriptive message (connection refused, TLS, timeout, etc.) instead of crashing or silently falling back to mock data.

They have not been verified against a live Nessus instance, since none was available in the environment this was built in. If you connect this to a real instance and something doesn't match (e.g. a template name your instance doesn't have, or a response field that differs by Nessus version), please open an issue.

License

MIT

Disclaimer

This server is not affiliated with or endorsed by Tenable. Nessus is a trademark of Tenable, Inc.

Available Tools

7 tools

get_scan_resultsC

Get the results of a completed scan

ParametersJSON Schema

Name	Required	Description	Default
`scan_id`	Yes	ID of the scan to get results for

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it retrieves results for completed scans, lacking details on permissions, rate limits, error handling, or response format. This is inadequate for a tool that likely returns complex data.

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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of scan results (likely involving vulnerabilities or security data), no annotations, and no output schema, the description is insufficient. It doesn't explain what 'results' include, how they're structured, or any prerequisites, leaving significant gaps for an agent to use the tool effectively.

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

Parameters3/5

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

The input schema has 100% description coverage, clearly documenting the 'scan_id' parameter. The description doesn't add any additional meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('results of a completed scan'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_scan_status' or 'list_scans', which could cause confusion about when to use each tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance by specifying 'completed scan', which implies it shouldn't be used for ongoing scans. However, it doesn't mention alternatives like 'get_scan_status' for status checks or 'list_scans' for scanning available scans, leaving the agent with little context for tool selection.

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

get_scan_statusC

Check the status of a running scan

ParametersJSON Schema

Name	Required	Description	Default
`scan_id`	Yes	ID of the scan to check

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool checks status but doesn't describe what the status includes (e.g., progress percentage, state like 'running'/'completed'), whether it's read-only (implied but not explicit), or any rate limits or authentication needs. This leaves significant gaps for an agent to understand the tool's behavior.

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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place, making it highly concise and well-structured for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a scanning tool with no annotations and no output schema, the description is insufficient. It doesn't explain what status information is returned (e.g., progress, errors) or behavioral aspects like idempotency or error handling, leaving the agent with incomplete context for effective use.

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

Parameters3/5

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

The input schema has 100% description coverage, with the 'scan_id' parameter clearly documented. The description adds no additional semantic context beyond implying the scan must be 'running', which is minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Check') and resource ('status of a running scan'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_scan_results' or 'list_scans', which could provide similar status information in different contexts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get_scan_results' or 'list_scans'. It mentions 'running scan' but doesn't clarify prerequisites (e.g., whether the scan must be actively executing) or exclusions (e.g., not for completed scans).

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

get_vulnerability_detailsC

Get detailed information about a specific vulnerability

ParametersJSON Schema

Name	Required	Description	Default
`vulnerability_id`	Yes	ID of the vulnerability (e.g., CVE-2021-44228)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the tool retrieves 'detailed information' but doesn't specify what details are included, whether it's a read-only operation, if authentication is required, or any rate limits. The description is too vague to inform the agent about operational traits beyond the basic purpose.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of vulnerability details (which could include technical data, severity scores, patches, etc.), no annotations, and no output schema, the description is insufficient. It doesn't hint at the type or structure of information returned, leaving the agent unprepared for what to expect from the tool's output.

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

Parameters3/5

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

Schema description coverage is 100%, with the parameter 'vulnerability_id' clearly documented in the schema as 'ID of the vulnerability (e.g., CVE-2021-44228)'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get detailed information') and target resource ('about a specific vulnerability'), making the purpose immediately understandable. It distinguishes from siblings like 'search_vulnerabilities' (which likely searches multiple) and 'get_scan_results' (which focuses on scan outputs). However, it doesn't explicitly contrast with siblings, keeping it from a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a vulnerability ID from another source), exclusions (e.g., not for bulk lookups), or direct comparisons to siblings like 'search_vulnerabilities' for broader queries. Usage is implied but not articulated.

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

list_scansB

List all scans and their status

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states what the tool does without disclosing behavioral traits like pagination, rate limits, or authentication needs. It's minimal and doesn't add meaningful context beyond the basic operation.

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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to understand quickly without unnecessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (0 parameters, no output schema), the description is adequate but has clear gaps. It lacks behavioral context and usage guidelines, which are needed for a tool with siblings, making it minimally viable but incomplete.

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

Parameters4/5

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

Since there are 0 parameters and schema description coverage is 100%, the baseline is high. The description doesn't need to compensate for missing param info, and it accurately reflects the lack of inputs by not mentioning any.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('all scans and their status'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_scan_status' or 'list_scan_templates', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get_scan_status' or 'search_vulnerabilities'. It lacks explicit context or exclusions, leaving usage decisions unclear.

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

list_scan_templatesB

List available Nessus scan templates

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention if this is a read-only operation, what the output format might be, or any constraints like rate limits, leaving significant gaps in understanding how the tool behaves.

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 a single, clear sentence with no wasted words, making it highly efficient and front-loaded. It directly communicates the core purpose without unnecessary elaboration, which is ideal for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimal but incomplete. It doesn't explain what 'scan templates' entail or provide context about the return values, leaving the agent with insufficient information to fully understand the tool's role in the Nessus ecosystem.

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

Parameters4/5

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

The tool has 0 parameters, and the input schema has 100% coverage with no properties. The description doesn't need to add parameter details, so it appropriately avoids redundancy. A baseline of 4 is applied since no parameters exist, and the description doesn't mislead about inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List') and target resource ('available Nessus scan templates'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'list_scans', which might list actual scans rather than templates, so it misses full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'list_scans' or 'start_scan'. It lacks context about prerequisites, such as whether authentication is needed or if this is for planning scans, leaving the agent with no usage direction.

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

search_vulnerabilitiesC

Search for vulnerabilities by keyword

ParametersJSON Schema

Name	Required	Description	Default
`keyword`	Yes	Keyword to search for in vulnerability names and descriptions

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches vulnerabilities but doesn't describe behavioral traits such as whether it's read-only (implied by 'search'), potential rate limits, authentication needs, or what the search returns (e.g., list of matches, error handling). The description is minimal and lacks critical context for safe and effective use.

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 extremely concise with a single sentence: 'Search for vulnerabilities by keyword'. It is front-loaded and wastes no words, making it easy to parse. Every part of the sentence contributes directly to the tool's purpose, earning its place efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a search operation with no output schema) and lack of annotations, the description is incomplete. It doesn't explain what the search returns, how results are formatted, or any limitations (e.g., partial matches, case sensitivity). For a tool that likely returns a list of vulnerabilities, more context is needed to guide the agent effectively.

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

Parameters3/5

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

The input schema has 100% description coverage, with the 'keyword' parameter fully documented in the schema. The description adds no additional meaning beyond what the schema provides—it mentions 'keyword' but doesn't elaborate on syntax, examples, or search behavior. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose as 'Search for vulnerabilities by keyword', which is clear but vague. It specifies the action (search) and resource (vulnerabilities) but lacks specificity about scope or differentiation from siblings like 'get_vulnerability_details' or 'list_scans'. It doesn't mention what aspects of vulnerabilities are searched (e.g., names, descriptions as implied by schema).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_vulnerability_details' for specific vulnerability info or 'list_scans' for broader scan results, nor does it specify contexts like preliminary investigation versus detailed analysis. Usage is implied only by the action 'search', with no exclusions or prerequisites stated.

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

start_scanC

Start a new vulnerability scan against a target

ParametersJSON Schema

Name	Required	Description	Default
`scan_type`	Yes	Type of scan to run (basic-network-scan, web-app-scan, compliance-scan)
`target`	Yes	Target IP address or hostname to scan

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool initiates a scan but lacks details on permissions required, whether it's asynchronous, rate limits, or what happens if a scan is already running. This is inadequate for a mutation tool with zero annotation coverage.

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 a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is front-loaded and appropriately sized for the task.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of starting a scan (a mutation operation) and the lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., a scan ID, status), error conditions, or behavioral traits, leaving significant gaps for the agent.

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

Parameters3/5

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

The schema description coverage is 100%, so the input schema already documents both parameters ('scan_type' and 'target') thoroughly. The description adds no additional meaning beyond implying these parameters are used to start the scan, meeting the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Start a new vulnerability scan') and the target ('against a target'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'list_scans' or 'get_scan_results', which are read-only operations, though this is implied by the verb 'Start'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a target configured), exclusions, or comparisons to siblings like 'list_scan_templates' or 'search_vulnerabilities', leaving the agent to infer usage context.

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

Tool Schema Changelog

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

7 tool updatesv1.0.0Aug 14, 2025
- First observedget_scan_results
- First observedget_scan_status
- First observedget_vulnerability_details
- First observedlist_scan_templates
- First observedlist_scans
- First observedsearch_vulnerabilities
- First observedstart_scan

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

B3.4/5.0

Scored 2026-04-18 10:20 across 7 tools

Disambiguation5/5

Every tool has a clearly distinct purpose with no ambiguity. For example, get_scan_results retrieves completed scan data, while get_scan_status checks ongoing scan progress, and list_scans provides an overview of all scans. The separation between vulnerability-focused tools (get_vulnerability_details, search_vulnerabilities) and scan-focused tools is also well-defined.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case throughout. The naming convention is perfectly uniform with clear action-object pairs like get_scan_results, list_scans, start_scan, and search_vulnerabilities. There are no deviations in style or structure across the tool set.

Tool Count5/5

With 7 tools, the count is well-scoped for a Nessus vulnerability scanning server. Each tool earns its place by covering essential operations such as scan management (start, list, check status), result retrieval, and vulnerability lookup, without being overly sparse or bloated.

Completeness4/5

The tool surface provides strong coverage for core vulnerability scanning workflows, including scan initiation, monitoring, result access, and vulnerability details. A minor gap exists in the lack of tools for modifying or deleting scans, which might limit full lifecycle management, but agents can still perform key operations effectively.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Os Automation Mcp C
io.github.varvararatta
MCP server for OS Automation
OS Automation Command Line
2
Security Mcp A
io.github.varvararatta
MCP server for Security
Security Penetration Testing
2
Support Service Management Mcp D
io.github.varvararatta
MCP server for Support & Service Management
Customer Support Project Management
2
Home Automation Mcp D
io.github.varvararatta
MCP server for Home Automation
Home Automation & IoT
2

Related MCP Servers

mcp-netbird
RAG Systems Databases
aantti
A
license
Not graded
quality
D
maintenance
MCP Server for Netbird
Updated a year ago (2025-04-16 13:27 UTC)
60
Apache 2.0
mcp-nutanix
Virtualization Cloud Platforms
thunderboltsid
A
license
Not graded
quality
F
maintenance
MCP Server for Nutanix Prism Central
Updated 8 months ago (2026-01-29 09:57 UTC)
13
MIT
Burpsuite MCP Server
Security Penetration Testing Developer Tools
Cyreslab-AI
A
license
B
quality
B
maintenance
Burpsuite MCP Server
Updated 10 days ago (2026-09-18 23:28 UTC)
5
8
MIT
Cortex MCP Server
Security Autonomous Agents
gbrigandi
A
license
Not graded
quality
C
maintenance
MCP Server for Cortex
Updated 10 months ago (2025-12-06 02:22 UTC)
16
MIT

Nessus MCP Server

Features

Tools

Installation

Prerequisites

Building from Source

Usage

Running in Mock Mode

Running with a real Nessus instance

Generating an API key pair

Self-signed certificates

Design notes on the real-mode mapping

Using with Claude for Desktop

Example Interactions

Starting a Scan

Getting Scan Results

Searching for Vulnerabilities

Development

Project Structure

Adding New Tools

Verification status

License

Disclaimer

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches