Rapid7 Bulk Export MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| load_rapid7_parquetA | Load vulnerability data from existing Parquet file(s). Use this if you already have Parquet files downloaded and want to skip the export process. This is much faster than running a full export. |
| start_rapid7_exportA | Start a new Rapid7 export job (non-blocking). This is a fast, non-blocking call that creates an export job on the Rapid7 platform and returns the export ID immediately. The export will process in the background on Rapid7's servers (typically 3-5 minutes). Use check_rapid7_export_status(export_id) to monitor progress, then download_rapid7_export(export_id, export_type="...") once it completes. If an export from today already exists, returns that export's ID instead of creating a duplicate. For remediation exports, the Rapid7 API limits each request to 31 days. If the date range exceeds 31 days, this tool automatically splits it into multiple 31-day chunks and kicks off an export for each chunk. |
| check_rapid7_export_statusA | Check the current status of a Rapid7 export job. This is a fast, non-blocking call that queries the Rapid7 API once and returns the current status. Does NOT poll or wait. |
| download_rapid7_exportA | Download a completed Rapid7 export and load into the database. Call this after check_rapid7_export_status confirms the export is COMPLETE. Downloads the Parquet files and loads them into the local DuckDB database for querying. |
| query_rapid7A | Execute a SQL query against the Rapid7 database. The database contains the following tables loaded from Rapid7 InsightVM Bulk Export API Parquet files: assets — Asset inventory data: Key fields: orgId, assetId, agentId, hostName, ip, mac, osFamily, osProduct, osVersion, osDescription, riskScore, sites, assetGroups, tags, awsInstanceId, azureResourceId, gcpObjectId vulnerabilities — Combined asset + vulnerability data: Key fields: orgId, assetId, vulnId, checkId, port, protocol, title, description, severity, severityRank, cvssScore, cvssV3Score, cvssV3Severity, hasExploits, epssscore, epsspercentile, riskScoreV2_0, cves, firstFoundTimestamp, reintroducedTimestamp, dateAdded, dateModified, datePublished, pciCompliant, pciSeverity policies — Policy compliance results (agent and scan based): Key fields: orgId, assetId, benchmarkNaturalId, profileNaturalId, benchmarkVersion, ruleNaturalId, ruleTitle, finalStatus, proof, lastAssessmentTimestamp, benchmarkTitle, profileTitle, publisher, fixTexts, rationales, source ('agent' or 'scan') vulnerability_remediation — Vulnerability remediation tracking: Key fields: orgId, assetId, cveId, vulnId, proof, firstFoundTimestamp, reintroducedTimestamp, lastDetected, lastRemoved, title, description, cvssV2Score, cvssV3Score, cvssV2Severity, cvssV3Severity, cvssV2AttackVector, cvssV3AttackVector, riskScoreV2_0, datePublished, dateAdded, dateModified, epssscore, epsspercentile Use this tool to query any of the above tables. You can filter, aggregate, join across tables, or perform any SQL-based analysis supported by DuckDB. Examples:
|
| get_rapid7_schemaA | Get the schema of all database tables. Returns column names and data types for all existing tables: assets, vulnerabilities, policies, and vulnerability_remediation. Tables that have not been loaded yet are omitted. Use this to understand what data is available before writing queries. Returns: Table schemas as formatted JSON, keyed by table name |
| get_rapid7_statsA | Get summary statistics for all database tables. Returns row counts and relevant distributions for all existing tables: assets, vulnerabilities, policies, and vulnerability_remediation. Tables that have not been loaded yet are omitted. Useful for getting an overview of the data across all loaded datasets. Returns: Summary statistics as formatted JSON, keyed by table name |
| purge_rapid7_dataA | Permanently delete all local Rapid7 data and tracking databases. This removes:
Use this when you are done with your analysis session, before handing off a machine, or to free disk space. After purging, you will need to run a new export to query data again. Returns: Confirmation of purged data. |
| list_rapid7_exportsA | List recent Rapid7 exports tracked in the system. Shows export metadata including export ID, date, status, type, and row counts. Useful for understanding what exports are available for reuse. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool covers a distinct phase of the export/query lifecycle: starting, checking, downloading, loading, listing, querying, inspecting, and purging. While list_rapid7_exports and check_rapid7_export_status both surface status information, their purposes are clearly separated and their descriptions remove ambiguity.
Tool names consistently follow a verb_rapid7_object pattern, such as start_rapid7_export, download_rapid7_export, and get_rapid7_schema. Even query_rapid7 fits the pattern by treating Rapid7 as the object, and pluralization is used sensibly for list_rapid7_exports.
Nine tools is well-scoped for the server's purpose: managing Rapid7 exports, loading data, and querying the local database. Each tool earns its place and there is no redundant bloat.
The tool set covers the complete export-to-analysis lifecycle: start an export, check status, download it, load existing Parquet files, list available exports, inspect schema and stats, query the data, and purge everything when done. No critical workflow dead-ends are apparent.