You can use this MCP server to query, investigate, and manage Lumu Defender security incidents from Claude via 13 tools.
Check server health with health_check.
List and filter incidents via get_incidents (by date range, status, adversary type, labels, with pagination or fetch_all chunked fetching).
Fetch incidents by status using dedicated get_open_incidents, get_muted_incidents, and get_closed_incidents tools (filterable by adversary type and labels).
Inspect a single incident with get_incident_details (status, IOCs, recommended actions).
Drill into incident context via get_incident_context (optional hash-type filter).
Review affected endpoints and contacts for an incident with get_incident_endpoints (filterable by endpoints/labels).
Triage and act on incidents: mark_incident_as_read, mute_incident, unmute_incident, and close_incident (each with optional explanatory comments).
Collaborate by adding notes with comment_incident.
Monitor activity in near real-time via get_incident_updates (offset/items/time window).
Note: the README also advertises event-grouping, label, and begin_work tools that are not present in this schema, while the schema adds get_incident_context and get_incident_endpoints not documented in the README.
Click on "Deploy 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., "@Lumu MCP Server Show me open security incidents from the last 30 days"
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.
Supercharge Claude Desktop with Lumu Defender security incident analysis
An MCP (Model Context Protocol) server that seamlessly integrates Claude Desktop with the Lumu Defender API, enabling AI-powered security incident analysis and management.
🔍 Incident Retrieval: Get security incidents with advanced filtering
🎯 Smart Analysis: AI-powered incident analysis through Claude
📊 Full Management: Mark as read, mute, unmute, and close incidents
🔬 Event Drill-down: Inspect incident event groupings and their raw security events
📈 Real-time Monitoring: Track incident updates and activity
🔐 Secure Integration: Environment-based API key management
⚡ Easy Setup: One-command installation with pip
Related MCP server: Pentest Tools MCP Server
Security requirement (TLS/certificate fixes, Oct 2026): install into a Python patched against CVE-2026-115557 — 3.11.18 / 3.12.16 / 3.13.18 / 3.14.10 or newer — and upgrade pip first. A fresh install then pulls a patched
certifi(≥ 2026.10.19) automatically viahttpx.python -m pip install --upgrade pip
pip install lumu-mcp-serverAdd to your claude_desktop_config.json:
{
"mcpServers": {
"lumu-mcp-server": {
"command": "lumu-mcp-server",
"env": {
"LUMU_DEFENDER_API_KEY": "your-api-key-here"
}
}
}
}Ask Claude: "Get security incidents from Lumu Defender"
💡 Need help finding your config file? See Configuration Locations below.
Log in to your Lumu Defender account
Navigate to Settings → API Keys
Generate or copy your API key
🍎 macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
🪟 Windows: %APPDATA%\Claude\claude_desktop_config.json
🐧 Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"lumu-mcp-server": {
"command": "lumu-mcp-server",
"env": {
"LUMU_DEFENDER_API_KEY": "your-api-key-here"
}
}
}
}If the command isn't found, use the Python module directly:
{
"mcpServers": {
"lumu-mcp-server": {
"command": "python",
"args": ["-m", "lumu_mcp_server"],
"env": {
"LUMU_DEFENDER_API_KEY": "your-api-key-here"
}
}
}
}If you use Claude Code (the terminal CLI) instead of the Claude Desktop app, register the server and pass the API key in one command — no JSON file to edit:
claude mcp add lumu-mcp-server \
-e LUMU_DEFENDER_API_KEY=your-api-key-here \
-- lumu-mcp-server-e KEY=value sets the environment variable the server reads.
-- separates Claude's own flags from the server command.
Add -s user to make it available in all your projects (default scope is the
current project). Avoid -s project with a real key, since that writes a
shared .mcp.json.
Then run /mcp inside a session to confirm it's connected, and remove it later
with claude mcp remove lumu-mcp-server.
Note:
claude mcp addconfigures Claude Code only — it does not affect the Claude Desktop app, which readsclaude_desktop_config.json(above).
All variables use the LUMU_ prefix and are read at startup by a single typed
configuration module. LUMU_DEFENDER_API_KEY is required — the server fails
fast with a clear message if it is missing. Everything else has a safe default.
Variable | Purpose | Type | Default | Required | Secret |
| Lumu Defender API key | string | — | ✅ yes | ✅ yes |
| Base URL of the Lumu Defender REST API | string |
| no | no |
| Per-request HTTP timeout (seconds) | float > 0 |
| no | no |
| Server name reported to clients | string |
| no | no |
|
| enum |
| no | no |
| Enable SDK debug mode | bool |
| no | no |
|
| enum |
| no | no |
The
LUMU_TRANSPORT/LUMU_HOST/LUMU_PORT/… transport variables apply only to the advanced HTTP transports. The default, and the only mode used by Claude Desktop, isstdio. See.env.examplefor the full list.
For local development you may place these in a git-ignored .env file (see
.env.example); in production, set them in the client's env block instead.
Restart Claude Desktop completely
Look for the 🔌 MCP icon in Claude Desktop
Test with: "Check the health of the lumu-mcp-server"
Once configured, you can interact with Lumu Defender through natural language:
"Check the health of the lumu-mcp-server"
"Is the Lumu integration working?"
"Get security incidents from Lumu Defender"
"Show me open security incidents from the last 30 days"
"Find all C2C and Malware incidents"
"Get incidents with status 'open' or 'muted'"
"Get details for incident [UUID]"
"Show me the full information about incident abc-123-def"
"Show me the event groupings for incident [UUID]"
"Get the raw events for grouping [ID] in incident [UUID]"
"Add a comment to incident [UUID]: 'Investigating with network team'"
"Mark incident [UUID] as read"
"Begin work on incident [UUID] and assign it to user 42"
"Mute incident [UUID] with comment 'False positive'"
"Close incident [UUID] with comment 'Threat resolved'"
"List the event groupings for incident [UUID]"
"Show me the raw security events for grouping [ID]"
"List all labels"
"What is label 7?"
"Get incident updates"
"Check for recent incident activity"
"Get all open Malware incidents, then show details for the most recent one"
"Find critical incidents that are still open and summarize their impact"
"List all muted C2C incidents and help me decide which to unmute"
"Show an incident's event groupings, then drill into the raw events"
health_checkReturns the server status. (The server requires a valid API key to start, so if it is running the key is configured.)
get_incidentsRetrieves security incidents with optional filters and pagination support.
Parameters:
from_date (optional): Start date in ISO format (default: 7 days ago). Max range: 90 days unless fetch_all is true.
to_date (optional): End date in ISO format (default: now)
status (optional): Array of statuses ["open", "muted", "closed"]
adversary_types (optional): Array of types ["C2C", "Malware", "DGA", "Mining", "Spam", "Phishing"]
labels (optional): Array of label IDs
page (optional): Page number for pagination (0-indexed, default: 0)
limit (optional): Number of items per page (default: 50, max: 100)
fetch_all (optional): If true, automatically fetches ALL incidents with pagination. Handles large date ranges by chunking.
Examples:
# Get incidents with pagination
"Get page 2 of incidents with 20 items per page"
# Get ALL incidents for a date range
"Get all incidents from May 1-31, 2026 with fetch_all=true"
# Get all malware incidents
"Get all Malware incidents with fetch_all=true"get_incident_detailsGet detailed information about a specific security incident.
Parameters:
incident_id (required): The UUID of the incident
Returns: Detailed incident information including status, IOCs, recommended actions, and more.
get_incident_events_groupingsRetrieve the event groupings of a specific incident (bundles of raw security events). Use the returned grouping IDs with get_security_event_details.
Parameters:
incident_id (required): The UUID of the incident
status (optional): Array of statuses ["open", "muted", "closed"]
page (optional): Page number for pagination (0-indexed, default: 0)
limit (optional): Items per page (default: 50, max: 100)
Returns: Event grouping IDs with status and event counts.
get_security_event_detailsRetrieve the raw data of a specific event group within an incident.
Parameters:
incident_id (required): The UUID of the incident
event_id (required): The event-grouping ID from get_incident_events_groupings
sort (optional): Sort order "asc" or "desc" (default: asc)
page (optional): Page number for pagination (0-indexed, default: 0)
limit (optional): Items per page (default: 50, max: 100)
Returns: Raw security events for the event group.
comment_incidentAdd a comment to a specific security incident.
Parameters:
incident_id (required): The UUID of the incident
comment (required): The comment text to add
Returns: Confirmation of the comment being added.
get_open_incidentsRetrieve only open security incidents.
Parameters:
adversary_types (optional): Array of types ["C2C", "Malware", "DGA", "Mining", "Spam", "Phishing"]
labels (optional): Array of label IDs
Returns: List of open incidents with filtering options.
get_muted_incidentsRetrieve only muted security incidents.
Parameters:
adversary_types (optional): Array of types ["C2C", "Malware", "DGA", "Mining", "Spam", "Phishing"]
labels (optional): Array of label IDs
Returns: List of muted incidents with filtering options.
get_closed_incidentsRetrieve only closed security incidents.
Parameters:
adversary_types (optional): Array of types ["C2C", "Malware", "DGA", "Mining", "Spam", "Phishing"]
labels (optional): Array of label IDs
Returns: List of closed incidents with filtering options.
mark_incident_as_readMark a security incident as read.
Parameters:
incident_id (required): The UUID of the incident to mark as read
Returns: Confirmation that the incident was marked as read.
mute_incidentMute a security incident.
Parameters:
incident_id (required): The UUID of the incident to mute
comment (optional): Comment explaining why the incident was muted
Returns: Confirmation that the incident was muted.
unmute_incidentUnmute a security incident.
Parameters:
incident_id (required): The UUID of the incident to unmute
comment (optional): Comment explaining why the incident was unmuted
Returns: Confirmation that the incident was unmuted.
get_incident_updatesGet real-time updates on incident operations (long-poll).
Parameters:
offset (optional): Starting offset for pagination (default: 0)
items (optional): Number of items to return, 1-100 (default: 50)
time (optional): Maximum seconds the server waits for updates (default: 5)
Returns: List of incident updates with timestamps in UTC (RFC 3339/ISO 8601 format).
close_incidentClose a security incident.
Parameters:
incident_id (required): The UUID of the incident to close
comment (optional): Comment explaining why the incident was closed
Returns: Confirmation that the incident was closed.
begin_workBegin work on a security incident and assign it to a user.
Parameters:
incident_id (required): The UUID of the incident
assignee (required): The numeric user ID to assign the incident to
comment (optional): Comment
Returns: Confirmation that work has begun and the incident is assigned.
list_labelsList labels configured in the Lumu account (label IDs are used by the incident labels filters).
Parameters:
page (optional): Page number for pagination (0-indexed, default: 0)
limit (optional): Items per page (default: 50, max: 100)
Returns: List of labels with id, name, and relevance.
get_labelGet a specific label by ID.
Parameters:
label_id (required): The numeric ID of the label
Returns: The label's name and relevance.
Check Claude Desktop logs: Help → Show Logs
Verify installation: pip list | grep lumu-mcp-server
Test command: Run lumu-mcp-server --help in terminal
Restart Claude Desktop completely
✅ Ensure API key is correctly set in claude_desktop_config.json
✅ Verify API key is valid in Lumu Defender portal
✅ Check Claude Desktop logs for authentication errors
✅ Test with: "Check the health of the lumu-mcp-server"
📅 Date Range: Try broader date ranges (e.g., last 30 days)
🔍 Filters: Remove status/type filters to see all incidents
🔑 Permissions: Ensure API key has proper incident access
💡 Tip: Ask Claude "Get incidents from the last 30 days"
🌐 Network: Verify internet connection to defender.lumu.io
🔒 Firewall: Ensure HTTPS traffic is allowed
🚀 Proxy: Configure proxy settings if needed
📖 Check QUICK_START.md for simplified setup
🐛 Report issues on GitHub
💬 Ask questions in discussions
🔐 API keys stored in environment variables, never in code
🌐 HTTPS encryption for all API communications
🚫 No data storage - all data fetched in real-time from Lumu
🛡️ Error sanitization prevents sensitive information leakage
📝 Audit trail through Lumu Defender's native logging
We welcome contributions! Please see our contribution guidelines:
git clone https://github.com/jpyoda/lumu-mcp.git
cd lumu-mcp-server
python -m venv venv
source venv/bin/activate # Windows: venv\Scripts\activate
pip install -e .lumu_mcp_server/
config.py # typed, env-driven settings (the only module reading env)
server.py # build_server(settings) -> MCPServer (composition root)
__main__.py # entrypoint: load settings -> build -> run
context.py # AppContext + get_client(ctx) for dependency injection
services/
lumu_client.py # LumuDefenderClient (async HTTP client)
tools/
health.py # health_check
incidents.py # incident query/listing tools
actions.py # incident mutation tools (incl. begin_work)
administration.py # labelsAPI Methods: Add a coroutine to lumu_mcp_server/services/lumu_client.py.
Tool: Add an @mcp.tool() function in the relevant tools/* module; the
SDK generates the input schema from the function signature and docstring.
Config: Add any new setting (with a docstring + default) to config.py.
MIT License - see LICENSE file for details.
🚀 Quick Setup: QUICK_START.md
🐛 Bug Reports: GitHub Issues
💬 Questions: GitHub Discussions
📧 Lumu API Issues: Contact Lumu Support
Built with ❤️ for the cybersecurity community
Enhance your security operations with AI-powered incident analysis
Close a security incident
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | The UUID of the incident to close | |
| comment | No | Optional comment for closing the incident |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like whether closing is reversible, required permissions, or side effects on related incidents.
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 a single, concise sentence that is front-loaded with the core action, but it could be slightly more informative without being verbose.
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 state-changing tool with no output schema and no annotations, the description is too brief. It lacks information about return values, effects, and how it fits with siblings like 'get_closed_incidents'.
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 100% with descriptions for both parameters, so the description adds no extra meaning beyond what the schema provides. Baseline score of 3 is appropriate.
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 'Close a security incident' clearly uses a specific verb and resource, distinguishing it from sibling tools like 'comment_incident' or 'get_open_incidents'.
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 prerequisites or when not to use it. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a comment to a specific security incident
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | The UUID of the incident to comment on | |
| comment | Yes | The comment text to add to the incident |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states 'Add a comment' but does not reveal if the operation is idempotent, requires permissions, triggers notifications, or has any side effects (e.g., appending vs. replacing). The agent is left to infer safety from the action name.
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 a single sentence with no redundant words. It is front-loaded with the verb 'Add' and immediately specifies the resource, achieving high efficiency.
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 (2 params, no output schema), the description is adequate but not complete. It lacks return value information and does not mention that the incident must exist. For a tool with no annotations, additional context about behavior would improve 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 100%, so baseline is 3. The description adds no extra meaning beyond the schema: both parameters are already well-described ('The UUID of the incident to comment on' and 'The comment text to add to the incident'). No format, length, or constraints are provided.
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 action (Add a comment) and the resource (specific security incident). It distinguishes from sibling tools like close_incident or get_incident_details, making its unique purpose unambiguous.
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 no guidance on when to use this tool versus alternatives, such as when the incident is closed or if any prerequisites exist. Sibling tools like close_incident or mute_incident suggest different contexts, but no exclusions or recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve closed security incidents from Lumu Defender with pagination support
| Name | Required | Description | Default |
|---|---|---|---|
| adversary_types | No | Filter by adversary types. If not specified, all types are returned | |
| labels | No | Filter by label IDs. If not specified, all labels are returned | |
| page | No | Page number for pagination (0-indexed). Default: 0 | |
| limit | No | Number of items per page (default: 50, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions pagination support; does not disclose read-only nature, rate limits, or other behavioral traits. Minimal 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?
Single sentence, concise and direct. Could be slightly restructured for clarity, but overall 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 paginated list tool with 4 optional parameters and no output schema, the description is too minimal. Does not explain return format, ordering, or default behavior for empty results.
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 100%, so parameters are already documented. The description adds no extra meaning beyond what schema provides. Baseline score of 3 is appropriate.
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 'Retrieve' and resource 'closed security incidents', and mentions pagination support. It distinguishes from siblings like get_open_incidents, but could specify what 'closed' means.
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 like get_incidents or get_open_incidents. With many sibling tools, the agent lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get context information for a specific security incident
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | The UUID of the incident to retrieve context for | |
| hash_type | No | Optional hash type for filtering context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation without side effects. With no annotations, it is minimally adequate but lacks details on what 'context information' includes or any potential limitations.
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 a single sentence that is concise and front-loaded. However, it could provide slightly more detail without becoming verbose.
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 exists, and the description does not explain what 'context information' is returned. Given the complexity of the tool (2 params, no annotations), the description is incomplete.
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 100%, so the description adds no value beyond the schema. The schema already explains both parameters sufficiently.
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 context information for an incident. However, it does not differentiate from sibling tools like get_incident_details or get_incident_endpoints, which also retrieve incident-related data.
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 (e.g., get_incident_details). No exclusions or prerequisites mentioned.
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 security incident
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | The UUID of the incident to retrieve details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as read-only nature, side effects, or required permissions. For a retrieval tool, basic transparency is missing.
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 a single sentence with no wasted words, but it lacks structure or additional helpful details. It is appropriately concise for a simple tool.
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 (one parameter, no output schema), the description is minimally complete. However, it could clarify what 'detailed information' includes to differentiate from siblings.
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 100% with a clear description for the single parameter. The description adds no additional meaning beyond what the schema already provides, achieving the baseline.
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 security incident', distinguishing it from sibling tools like 'get_incidents' (list) and 'get_incident_context' (context-specific).
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, nor any prerequisites or exclusions. The description lacks contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve endpoints and contacts for a specific security incident
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | The UUID of the incident | |
| endpoints | No | Filter by specific endpoint IPs or names | |
| labels | No | Filter by label IDs. If not specified, all labels are returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only says 'Retrieve', which implies a read-only operation. However, it does not disclose any behavioral traits such as pagination, rate limits, or side effects. For a read tool, the burden is lower, but minimal transparency is offered beyond the verb.
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 a single, clear sentence with no unnecessary words. It is front-loaded with the action and resource. However, it could be slightly more informative without sacrificing conciseness.
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?
While the tool name and schema hint at the data, the description lacks detail about the return format or structure of 'endpoints and contacts'. Given no output schema and no additional context, the description is incomplete for an agent to fully understand what the tool returns.
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 100%, so each parameter already has a description. The tool description adds no additional meaning or context beyond what the schema provides. Baseline score of 3 is appropriate as the description does not enhance parameter understanding.
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 action ('Retrieve') and the resource ('endpoints and contacts for a specific security incident'). It differentiates from sibling tools like close_incident or get_incidents, but does not explicitly distinguish from similar retrieval tools like get_incident_context or get_incident_details, leaving slight ambiguity.
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, nor are there any prerequisites, limitations, or use-case hints. The description merely states the action without contextual or conditional advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve security incidents from Lumu Defender API with pagination support
| Name | Required | Description | Default |
|---|---|---|---|
| from_date | No | Start date in ISO format (e.g., 2024-01-01T00:00:00Z). Default: 7 days ago. Max range: 90 days unless fetch_all is true. | |
| to_date | No | End date in ISO format (e.g., 2024-01-08T00:00:00Z). Default: now | |
| status | No | Filter by incident status. If not specified, all statuses are returned | |
| adversary_types | No | Filter by adversary types. If not specified, all types are returned | |
| labels | No | Filter by label IDs. If not specified, all labels are returned | |
| page | No | Page number for pagination (0-indexed). Default: 0 | |
| limit | No | Number of items per page. Default: 50, max: 100 | |
| fetch_all | No | If true, automatically fetches ALL incidents with pagination. Handles large date ranges by chunking. Use this to get complete incident lists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions 'pagination support' but does not elaborate on key behaviors like automatic fetching via fetch_all, date range limits (90 days unless fetch_all is true), or the fact that it can return large volumes of data. The description lacks details on side effects, authentication needs, or performance implications.
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 a single sentence that efficiently states the core purpose and highlights pagination support. It is front-loaded with the action and resource. While more detail could be beneficial, the brevity avoids unnecessary verbosity. However, it could be slightly longer to cover key behavioral aspects without becoming overly long.
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 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain the return format, how pagination works in practice, or how the tool relates to its many siblings. The description should provide context about the result structure, expected data volume, and usage patterns to fully equip an AI 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?
Since schema description coverage is 100%, the baseline is 3. The description adds minimal value beyond the schema, only noting 'pagination support'. The schema already provides detailed descriptions for all 8 parameters, including defaults, constraints, and the fetch_all behavior. The description does not enrich parameter understanding further.
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 'Retrieve' and the resource 'security incidents', establishing a clear purpose. However, it does not differentiate this tool from sibling tools like get_closed_incidents or get_open_incidents, which also retrieve incidents with specific filters. The description could explicitly indicate that this tool retrieves all incidents (with optional status filters) to distinguish it.
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 no guidance on when to use this tool versus its alternatives (e.g., get_closed_incidents, get_open_incidents). It does not mention conditions, prerequisites, or scenarios where this tool is preferred or should be avoided. Users are left to infer usage from the schema and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time updates on incident operations
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Starting offset for pagination (default: 0) | |
| items | No | Number of items to return (default: 50) | |
| time | No | Time window in minutes for updates (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'real-time updates' but does not disclose behavior like polling, side effects, or data freshness guarantees. Minimal behavioral insight.
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 a single, clear sentence. It is front-loaded with the purpose, no fluff. However, it is slightly under-informative, earning a 4 instead of 5.
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 annotations, the description is too brief. It omits return format, pagination details, and how 'real-time' is implemented, leaving gaps for a 3-parameter 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?
Schema coverage is 100% with good parameter descriptions, so baseline is 3. The description adds no extra meaning about parameters, achieving the baseline.
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 resource 'incident updates', implying a live feed distinct from siblings like get_incident_details or get_incidents. The word 'real-time' adds specificity.
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 no guidance on when to use this tool vs alternatives such as get_incident_details or get_open_incidents. Missing explicit context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve muted security incidents from Lumu Defender with pagination support
| Name | Required | Description | Default |
|---|---|---|---|
| adversary_types | No | Filter by adversary types. If not specified, all types are returned | |
| labels | No | Filter by label IDs. If not specified, all labels are returned | |
| page | No | Page number for pagination (0-indexed). Default: 0 | |
| limit | No | Number of items per page (default: 50, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only mentions pagination support, which is already implied by parameters. It does not mention read-only nature, authentication, rate limits, or any 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 a single, focused sentence that front-loads the action and resource. It contains no fluff and efficiently conveys the core functionality.
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 is provided, and the description does not describe what is returned (e.g., a list of incident objects, fields, or pagination metadata). The description is incomplete for an agent to fully understand the tool's 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 100%, so baseline is 3. The description adds no meaning beyond the schema; it simply restates pagination support, which is already described in parameter schemas.
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 'Retrieve', the resource 'muted security incidents', and the platform 'Lumu Defender'. It distinguishes the tool from siblings like get_incidents and get_open_incidents by specifying the 'muted' status.
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 does not provide guidance on when to use this tool versus alternatives. It only states what it does, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve open security incidents from Lumu Defender with pagination support
| Name | Required | Description | Default |
|---|---|---|---|
| adversary_types | No | Filter by adversary types. If not specified, all types are returned | |
| labels | No | Filter by label IDs. If not specified, all labels are returned | |
| page | No | Page number for pagination (0-indexed). Default: 0 | |
| limit | No | Number of items per page (default: 50, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses it's a read operation with pagination, but does not mention authentication, rate limits, or response structure. Adequate for a simple retrieval tool.
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?
Single sentence that is front-loaded with the action and key resource. No unnecessary words, highly efficient.
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 exists, and the description does not clarify the return format (e.g., list of incident objects). For pagination, it could mention metadata. Adequate but not comprehensive given the missing 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?
Schema coverage is 100%, so all parameters are described. The description adds no extra meaning beyond the schema, meeting the baseline for parameter documentation.
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 uses specific verb 'Retrieve' and resource 'open security incidents' with pagination support, clearly distinguishing from sibling tools like get_closed_incidents and get_muted_incidents.
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 sibling list implies differentiation via tool names, but no 'when to use' or 'when not to use' is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the health status of the server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation, but without annotations, it does not explicitly state there are no side effects. However, the nature of a health check is generally safe and non-destructive.
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 a single sentence that is concise and front-loaded. It contains no unnecessary 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?
Given the tool's simplicity (no parameters, no output schema), the short description is adequate. It could mention what the health check includes or returns, but it is not critically missing.
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 parameters exist, so schema coverage is 100%. The description does not need to add parameter meaning, and the baseline for 0 parameters is appropriate.
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 'check' and the resource 'health status of the server'. It distinguishes from sibling tools which are all incident-related.
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. Context signals show no sibling health tools, but the description does not explicitly state when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a security incident as read
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | The UUID of the incident to mark as read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the action 'mark as read' without explaining side effects, irreversibility, or what 'read' means in the security incident context.
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 a single, front-loaded sentence. It is appropriately concise for a simple action, though slightly underspecified for behavioral depth.
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, no output schema, and no annotations, the description gives the minimal purpose but lacks behavioral context needed for safe invocation by an AI 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?
Schema coverage is 100% for the single required parameter (incident_id). The description adds no extra meaning beyond the schema; baseline 3 is appropriate.
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 a specific verb ('mark') and resource ('incident as read'), clearly distinguishing from sibling tools such as close_incident, mute_incident, etc.
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 (e.g., close_incident, mute_incident, or comment_incident). The AI agent has no context to decide based on the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mute a security incident
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | The UUID of the incident to mute | |
| comment | No | Optional comment for muting the incident |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose side effects, permissions, or what muting entails (e.g., whether it silences notifications, prevents future updates, or is reversible).
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 a single, front-loaded sentence with no extraneous words. However, it sacrifices detail for brevity, which slightly lowers the score.
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 only two parameters, the description should explain what muting does to the incident (e.g., suppresses alerts). It fails to provide that context, leaving the tool incomplete for an 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 schema already describes both parameters (incident_id and comment) with 100% coverage. The description adds no further meaning 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 'Mute a security incident' clearly states the action (mute) and the resource (security incident). The sibling tool 'unmute_incident' further helps distinguish it as the opposite operation.
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 'close_incident' or when not to mute. The description implies usage only through the verb 'Mute'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unmute a security incident
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | The UUID of the incident to unmute | |
| comment | No | Optional comment for unmuting the incident |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks any behavioral details such as side effects, idempotency, permissions, or consequences of unmuting.
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 a single concise sentence, but it is under-specified for completeness; front-loads purpose but lacks detail.
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 should clarify prerequisites (e.g., incident must be muted) and related operations; it is incomplete.
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 100%, so parameters are documented; description adds no extra meaning beyond what schema provides, meeting baseline.
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 'Unmute' and the resource 'security incident', distinguishing it from the sibling 'mute_incident' tool.
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 like 'mute_incident' or other incident tools; usage is only implied.
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.
v1.1.0close_incidentcomment_incidentget_closed_incidentsget_incident_contextget_incident_detailsget_incident_endpointsget_incident_updatesget_incidentsget_muted_incidentsget_open_incidentshealth_checkmark_incident_as_readmute_incidentunmute_incidentScored across 14 tools
Each tool targets a distinct aspect of incident management (e.g., close, comment, get details, mute) with no overlap. Even similar tools like get_incident_details and get_incident_context are clearly differentiated.
All tools follow the verb_noun pattern in snake_case (e.g., close_incident, get_open_incidents). health_check is a slight deviation but is a standard term and fits naturally.
14 tools cover the full range of incident operations without being excessive. Each tool serves a clear purpose, and the count is well-suited for a security incident management server.
The set covers retrieval, query by status, muting, closing, commenting, and health checks. Missing an explicit reopen or update incident details tool, but core workflow is complete.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
MCP server enabling AI agents to manage Bitrix24 features via standardized protocol
