EyalSec MCP Server

Official

by EyalSec

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Search events

search_events

Read-onlyIdempotent

Query EyalSec security events newest first, filtered by severity, tags, dates, machine, or run. Paginate automatically and pass event IDs to get stack traces.

Instructions

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 limit events, the history is exhausted, or it has read 10 pages. If next_cursor in the answer is not empty, call again with it to continue. Each event carries its id; pass it to get_event for the stack trace, origin and runs.

Input Schema

TableJSON Schema

Name	Required	Description
`sort`	No	'newest' (default) or 'severity' (most severe first).
`tags`	No	Impact classes to keep, such as 'xss' or 'sqli'.
`view`	No	Which product's events: 'python' (es-python) or 'browser' (es-chromium). Omit for every product on the account.
`limit`	No	Stop once at least this many events are collected (whole pages of up to 100).
`bucket`	No	'live' (default: events not suppressed), 'suppressed', or 'all'.
`cursor`	No	next_cursor from a previous call with the same filters, to continue.
`labels`	No	Label ids (from list_labels) to keep.
`date_to`	No	End date, YYYY-MM-DD or RFC3339; includes that whole day.
`machine`	No	One machine, by its display name (exact match).
`run_uid`	No	Only events produced by this run (a run_uid from list_runs or get_event). es-python only.
`sources`	No	Keep only these taint source categories.
`advanced`	No	The events page condition builder, passed through as is: {"match": "all"\|"any", "conditions": [{"field": "sink", "op": "contains", "value": "sql", "negate": false}]}.
`severity`	No	Keep only these severities.
`xss_only`	No	Only es-chromium events whose sink can run script. Needs view='browser'.
`date_from`	No	Start date, YYYY-MM-DD or RFC3339.
`value_chars`	No	Cut each event's str_repr to this many characters (0 = no cut).
`sink_exclude`	No	Case-insensitive regex; drop events whose sink label ('where') matches.
`sink_include`	No	Case-insensitive regex; keep only events whose sink label ('where') matches.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 15, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, lowering the burden. The description adds valuable execution context beyond annotations: automatic paging until limit/history/10 pages, the reason short pages can still have more results, and the meaning of next_cursor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose in the first sentence, then explains paging and cursor continuation in a compact paragraph, ending with a useful pointer to get_event. Every sentence adds distinct value and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 18-parameter schema and an output schema, the description supplies the key operational contract: how paging behaves, how to continue with next_cursor, and how to use event ids. It omits guidance on filter combination or auth/account requirements, but those are either schema-covered or non-critical for this read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 18 parameters in detail. The description only adds the general framing that filters mirror the dashboard events page and mentions limit and cursor behavior, which is marginal beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List events') with scope ('from the EyalSec account'), default ordering ('newest first'), and filter provenance ('same filters as the dashboard's events page'). This clearly distinguishes it from siblings like get_event (single event), event_stats, and event_counts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for pagination continuation ('If next_cursor in the answer is not empty, call again with it') and points to get_event for per-event detail. It does not explicitly exclude sibling tools or say when another listing tool is preferable, but the intended use is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.