EyalSec MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EYALSEC_URL | No | Your EyalSec address. Defaults to https://eyalsec.com; set it only if your account lives on another domain. Must be https://. | https://eyalsec.com |
| EYALSEC_API_KEY | Yes | Your EyalSec API key, from Settings > API access. A read-only key is sufficient. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_eventsA | List events from the EyalSec account, newest first, with the same filters as the dashboard's events page. Follows the API's paging for you: a selective filter can return short or empty pages that still have
more behind them, so this keeps reading until it has |
| get_eventA | Get one event's full detail: stack trace, where the data came in (origin), where the value was created, nearby source code when the machine sends it, your note, and the runs (program invocations) that produced it. |
| event_statsB | The dashboard summary: total hits, distinct event types, counts for the last hour, day and week, the top event types, recent events and a 14-day timeline. |
| event_countsC | How many events the account has: per product list, live versus suppressed, and the count toward the monthly event quota (pass view for the number one product's list is capped by). |
| list_event_namesA | The distinct sink labels (the 'where' field) across the account's events, useful for building filters. |
| event_mapB | The es-python events as a graph: which sources untrusted data came from, which files it was read from, and which operations (sinks) it reached, each with event and hit counts and the worst severity. Prefer a date window on a large account. |
| list_runsA | The runs behind the account's events, newest first. A run is one invocation of one monitored program, with its command line, how many distinct events it produced and how many times. Pass a run_uid to search_events to see only that run's events. |
| ci_findingsA | What programs on one es-python machine reported since a moment: counts by severity, how many are at or above a threshold, which ones no earlier run had reached, and the findings themselves (ids, not values). |
| list_saved_searchesC | The account's saved events-page searches for one product. |
| list_labelsA | The account's triage labels (id, name, color). Use an id in search_events' labels filter. |
| list_machinesB | Every machine on the account: name, status, public_id, OS target, installed and newest build, Python version, product, and flags for a clone, a stalled install or an old copy still reporting. |
| supported_targetsB | The Linux distributions, architectures and Python versions es-python can be installed for. Needs no API key. |
| list_rulesC | The rules in one scope. Mode 1 = Hide, 2 = Show, 3 = Raise, 4 = Don't send. |
| list_filtersC | The account's event filters (standing blacklist or whitelist patterns on the events page). |
| get_taint_settingsA | Which kinds of incoming data a scope treats as untrusted. Each setting is on, off or unset (unset inherits from the level above). |
| get_event_uniquenessC | What makes two detections count as the same event for one product and scope. |
| list_rule_templatesA | Every rule template the account can see (its own and the EyalSec ones), with their rules and categories. |
| get_accountA | The account's profile, limits and permissions, the API key's scope and expiry (never the key itself), and how far es-python setup has got, with the next step. |
| list_activityA | The account's audit trail, newest first, 50 per page, kept for 30 days: sign-ins, machine changes, key generation and API calls. |
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 19 tools
Most tools target clearly distinct resources (events, runs, machines, rules, filters, labels, account). Minor overlap exists between event_stats (dashboard summary) and event_counts (per-product/quota counts), and between list_event_names (sink labels) and list_labels (triage labels), which could cause occasional misselection.
Consistent snake_case throughout, with a predictable verb_noun pattern for most tools (list_rules, get_event, search_events). A subset deviates to bare noun_phrases (event_stats, event_counts, event_map, ci_findings, supported_targets), which is a minor but noticeable inconsistency.
19 tools is slightly above the ideal 3-15 range but justified by a broad security-monitoring domain spanning events, runs, machines, rules, filters, labels, findings and account state. Each tool maps to a distinct capability, so nothing feels padded.
The surface is heavily read-only: many list_*/get_*/search_* tools but no create/update/delete for rules, filters, labels, saved searches or machines. Core investigation workflows are well covered, but lifecycle/mutation operations are notably absent, limiting it as a full management surface.