# Logz.io MCP for AI Agents AI Agent Connect > Logz.io MCP for AI agents. Query logs, manage alerts, and monitor triggered events in Logz.io directly from your AI agent using Elasticsearch DSL. Stop jumping between tabs to find errors. Ask your agent to pull specific log data, toggle alerts, or audit security rules in seconds. ## Overview - **Category:** devops-cicd - **Price:** Free - **Endpoint:** https://edge.vinkius.com/vk_preview_AyHNLvDaCmsIfrOJPVFCkVxu65F4CtNzZtKWGH3a/ai-agent-connect - **Tags:** logging, elasticsearch, siem, infrastructure-monitoring, alerting ## Description Managing logs and alerts usually involves a lot of clicking through complex dashboards and memorizing specific query syntaxes. If you're an engineer on call, you don't want to be hunting for a specific error pattern in a sea of data while the clock is ticking. This Connector changes that by letting you talk to your logs instead of digging for them. You can ask your agent to find specific failures, check the status of your security rules, or see what triggered an alert at 3 AM. It handles the heavy lifting of complex queries so you can stay focused on fixing the problem. You'll find this in the Vinkius catalog alongside other observability tools to help round out your stack. It's about getting the right information faster, whether you're hunting a production bug or auditing a security incident. ## Tools ### create_user Create a new user in your account. Use this to manage team access and permissions easily. ### disable_alert Disable an alert immediately. This is perfect for silencing noisy notifications during maintenance windows. ### enable_alert Enable an alert to start receiving notifications. Use this to turn on monitoring for new infrastructure. ### list_insights Retrieve LOGCEPTION and PUBLIC_CI insights from your logs. This highlights specific issues detected by the platform. ### create_metrics_account Create a new Metrics account in your platform. This allows you to track specific performance data points in one place. ### create_security_rule Create a new SIEM security rule to catch specific threats. This helps you automate the detection of malicious activity. ### create_siem_account Create a new SIEM account linked to your main logs. This organizes your security monitoring data. ### create_snapshot Create a Kibana snapshot for your data. This ensures you have reliable backups for long-term retention. ### delete_alert Delete an alert from your configuration. This helps you clean up noisy or obsolete notifications. ### delete_security_rule Delete a SIEM security rule. Use this to remove rules that are no longer relevant to your security posture. ### delete_user Delete a user from your account. This is useful for offboarding team members or cleaning up old accounts. ### get_lookup_list Get a lookup list by its ID. This helps you retrieve specific reference data used in your rules. ### get_snapshot Get a specific Kibana snapshot. Use this to verify that your data backups are available. ### list_alerts List all configured alerts in your account. This gives you a full overview of your current monitoring setup. ### list_triggered_alerts List a paged set of triggered alert events. This helps you quickly see what's currently failing. ### list_users_recursive List all users in the main account and sub-accounts. Use this to audit permissions across your entire organization. ### list_users List users for a single account. This is useful for checking permissions on a per-environment basis. ### scroll_logs Paginate through large result sets from your searches. This allows you to see more data without hitting limits. ### search_logs Search account data using Elasticsearch Search API DSL. This lets you run complex queries to find specific log entries. ### search_lookup_lists Search through your lookup lists. Use this to find specific reference data like blacklisted IPs. ### search_security_event_logs Retrieve the specific logs that caused a security event to trigger. This helps you find the root cause of a threat. ### search_security_events Fetch events triggered by your security rules. Use this to see a history of security incidents. ### search_security_rules Search through your SIEM security rules. This helps you find and manage your security logic. ### suspend_user Suspend a user account. This is a quick way to revoke access during a security incident. ### unsuspend_user Unsuspend a user account. Use this to restore access once a security concern is resolved. ### update_alert Update an existing alert configuration. Use this to tune thresholds or change notification targets. ### update_security_rule Update a SIEM security rule. This allows you to refine your security logic as your environment changes. ### update_user Update the details of an existing user. Use this to manage permissions and account info. ### create_alert Create a new alert for your monitoring system. Use this to set up new notifications for your infrastructure. ### create_deployment_markers Add deployment markers to your Kibana exception graphs. This helps you correlate deployments with errors. ### create_lookup_list Create a new lookup list for use in SIEM rules. This is great for managing blacklists or allowed IPs. ## Prompt Examples **Prompt:** ``` Find the last 5 error logs from the production cluster. ``` **Response:** ``` I've searched the production logs for errors. Here are the 5 most recent entries: | Timestamp | Level | Message | | :--- | :--- | :--- | | 10:01:05 | ERROR | Connection timeout in cluster-01 | | 10:01:12 | ERROR | Database query exceeded 5s | | 10:02:45 | ERROR | Auth service unreachable | | 10:03:10 | ERROR | Cache miss on user_session | | 10:04:01 | ERROR | Disk space warning on node_4 | Would you like me to pull more details on any of these? ``` **Prompt:** ``` Which alerts are currently disabled? ``` **Response:** ``` I've checked your alert configurations. You currently have 2 alerts disabled: * **High Latency DB** (Disabled during maintenance) * **Disk Space Warning** (Disabled for node_4) All other 8 alerts are currently active. ``` **Prompt:** ``` Show me the security rules for unauthorized access. ``` **Response:** ``` I found 3 security rules related to unauthorized access: 1. **Brute Force Detection**: Triggers when >5 failed logins occur in 1 minute. 2. **Admin Login Alert**: Triggers on logins from new IP addresses. 3. **Privilege Escalation**: Monitors for changes to root permissions. Would you like to see the logs triggered by any of these rules? ``` ## Capabilities ### Query complex logs Run advanced Elasticsearch DSL queries to find specific data points across your infrastructure. ### Manage monitoring alerts Create, update, and toggle alerts to control your notification flow. ### Monitor triggered events Retrieve a filtered list of alerts that have actually fired to identify critical issues. ### Audit security rules Search and inspect SIEM security rules and the specific logs that triggered them. ### Handle user permissions Manage user accounts, including creating, suspending, and listing users across platforms. ### Manage data snapshots Create and retrieve Kibana snapshots for data retention and management. ## Use Cases ### Rapid Incident Response An SRE gets a page at 2 AM and asks the agent to list all high severity alerts from the last hour, then pulls the specific logs for the top result. ### Security Threat Hunting A security analyst identifies a suspicious rule trigger and asks the agent to find the raw log entries that caused the event. ### Alert Tuning and Maintenance A DevOps engineer wants to silence a noisy alert and then update its threshold to reduce false positives during a maintenance window. ### User Access Auditing A platform admin needs to see every user across all sub-accounts and then suspend a specific account that shows suspicious activity. ## Benefits - Stop memorizing complex Elasticsearch DSL syntax by asking your agent to run queries for you. - Manage your monitoring state instantly by toggling alerts during an active incident response. - Find security threats faster by quickly identifying the exact logs that triggered a security rule. - Audit your user base across multiple accounts to ensure your permissions are correctly configured. - Handle large data sets without hitting limits by using automated pagination for your search results. - Identify the root cause of a security trigger by pulling the raw log data in a single step. ## How It Works The bottom line is you get a conversational interface for your entire Logz.io observability stack. 1. Subscribe to the Logz.io MCP via the Vinkius Marketplace. 2. Provide your Logz.io API Token and specify your preferred region. 3. Ask your AI client to query logs, check alert statuses, or manage security rules. ## Frequently Asked Questions **Can the Logz.io MCP search logs using plain English?** Yes, it interprets your natural language into complex queries. You can ask for specific errors, timeframes, or infrastructure components, and it handles the technical syntax for you. **Can I use this to manage my alerts?** Yes, you can create new alerts, update existing ones, or toggle them on and off. It's a great way to manage your monitoring state during an active incident. **Does this work for security events?** Yes, it can search security rules and find the specific log entries that triggered them. This makes it much faster to investigate security incidents. **Can I manage users with this?** Yes, you can list users across your main account and sub-accounts, create new users, and suspend or unsuspend them as needed for access control. **How do I handle large log results?** The agent handles large result sets by paginating through the data. This ensures you can see all relevant logs without hitting any system limits. **Is this for any log provider?** No, this Connector is specifically designed for the Logz.io platform. It connects directly to your Logz.io account to manage logs and alerts. **Can I perform complex log searches using Elasticsearch DSL?** Yes. The `search_logs` tool accepts a full Elasticsearch DSL query object, allowing you to filter, aggregate, and sort your log data with high precision. **How do I check which alerts have been triggered recently?** Use the `list_triggered_alerts` tool. You can filter the results by severity, tags, or search for specific alert names to identify active incidents. **Is it possible to temporarily stop an alert without deleting it?** Absolutely. You can use the `disable_alert` tool with the specific Alert ID to pause it, and `enable_alert` to turn it back on whenever you're ready.