cortex-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CORTEX_URL | Yes | Cortex base URL (e.g., https://cortex.example.com:9001) | |
| CORTEX_API_KEY | Yes | API key for authentication | |
| CORTEX_VERIFY_SSL | No | Set to false to skip SSL verification | true |
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
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cortex_list_analyzersA | List all enabled analyzers, optionally filtered by data type |
| cortex_get_analyzerA | Get details about a specific analyzer by ID |
| cortex_run_analyzerC | Submit an observable to a specific analyzer for analysis |
| cortex_run_analyzer_by_nameB | Run an analyzer by name instead of ID (convenience wrapper) |
| cortex_run_analyzer_fileB | Submit a file to a specific analyzer for analysis. Provide a file path or base64-encoded content. |
| cortex_get_jobA | Get the status and details of an analysis job |
| cortex_get_job_reportA | Get the full report of a completed analysis job |
| cortex_wait_and_get_reportB | Wait for a job to complete and return the full report (with polling timeout) |
| cortex_list_jobsC | List recent analysis jobs with optional filters |
| cortex_get_job_artifactsA | Get artifacts (extracted observables/IOCs) from a completed analysis job |
| cortex_delete_jobA | Delete a specific analysis job by ID. DESTRUCTIVE: requires confirm=true. |
| cortex_cleanup_jobsA | Delete multiple jobs by status or age. Useful for cleaning up failed or old jobs. |
| cortex_list_respondersA | List all enabled responders, optionally filtered by data type |
| cortex_run_responderA | Execute a responder action against a TheHive entity (case, task, artifact, alert). DESTRUCTIVE: responders perform real-world side effects (blocking IPs, sending mail, isolating hosts). Gated behind the CORTEX_ALLOW_DESTRUCTIVE env var AND confirm=true. |
| cortex_analyze_observableA | Run applicable analyzers against an observable and collect aggregated results with taxonomy summary. Can auto-detect data type. By default only an explicit allowlist of analyzers runs; set fanOut=true to submit to every applicable analyzer (capped by CORTEX_MAX_FANOUT). Fanning out submits the observable to many third-party services (SSRF-by-proxy / IOC disclosure / quota burn), so it is opt-in. |
| cortex_list_analyzer_definitionsA | List all available analyzer definitions (installed but not necessarily enabled). Filter by data type or find analyzers that require no API keys. |
| cortex_enable_analyzerA | Enable an analyzer definition in the current organization. Provide configuration values for any required fields. |
| cortex_disable_analyzerA | Disable (remove) an enabled analyzer from the current organization. DESTRUCTIVE: requires confirm=true. |
| cortex_list_responder_definitionsA | List all available responder definitions (installed but not necessarily enabled). Filter by data type or find responders that require no API keys. |
| cortex_enable_responderC | Enable a responder definition in the current organization. Provide configuration values for any required fields. |
| cortex_disable_responderA | Disable (remove) an enabled responder from the current organization |
| cortex_get_statusA | Get Cortex instance health status, version info, and configuration |
| cortex_list_organizationsA | List all organizations (requires superadmin API key via CORTEX_SUPERADMIN_KEY) |
| cortex_get_organizationA | Get details about a specific organization (requires superadmin API key) |
| cortex_create_organizationA | Create a new organization in Cortex (requires superadmin API key) |
| cortex_update_organizationB | Update an organization's description or status (requires superadmin API key) |
| cortex_list_usersA | List all users across organizations (requires superadmin API key via CORTEX_SUPERADMIN_KEY) |
| cortex_get_userA | Get details about a specific user (requires superadmin API key) |
| cortex_create_userA | Create a new user in an organization (requires superadmin API key) |
| cortex_renew_user_keyA | Generate a new API key for a user (invalidates the previous key). Requires superadmin API key. |
| cortex_get_user_keyA | Get the current API key for a user. Requires superadmin API key. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| analyze-observable | Guided workflow for analyzing an observable through Cortex analyzers |
| investigate-ioc | Deep investigation workflow for a suspicious indicator of compromise |
| setup-cortex | Guided workflow to set up a fresh Cortex instance with analyzers and responders |
| triage-alert | Guided workflow for triaging a security alert using Cortex analysis |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| analyzers | List of all enabled Cortex analyzers with their capabilities and supported data types |
| analyzer-definitions | All available Cortex analyzer definitions (installed, not necessarily enabled) with config requirements |
| responder-definitions | All available Cortex responder definitions with config requirements |
| recent-jobs | Recent Cortex analysis jobs (last 50) |
TDQS
Scored across 31 tools
Each tool has a clearly distinct purpose: analyzers, responders, jobs, organizations, and users are separate domains. Within each, operations are unique (list, get, create, update, delete, enable, disable, run). Descriptions clarify any potential overlap, e.g., cortex_analyze_observable vs cortex_run_analyzer.
All tools follow a consistent `cortex_verb_noun` pattern with snake_case. Verbs like list, get, create, run are used uniformly. Even compound verbs like `wait_and_get` fit the pattern. No mixing of styles.
With 31 tools, this is a large set, but each tool corresponds to a specific operation in the Cortex security analysis platform. The count is slightly above the typical well-scoped range but justified by the platform's complexity and the need to cover analyzers, responders, jobs, organizations, and users.
The tool set covers core CRUD operations for analyzers, responders, jobs, organizations, and users. Notable gaps include missing delete tools for users and organizations, and no update for users besides key renewal. But the main analysis workflow is fully covered, and the gaps are minor.