AEGIS Events

Search events

search_events

Read-only

Search risk events (crime, natural hazards, armed conflict, logistics and infrastructure disruptions, protests and other mass social events) by meaning, exact names and filters, e.g. "protests in Istanbul this week", "stabbings in Lisbon", "airport disruptions in Frankfurt".

Returns events (newest or best match first), next_cursor for the next page,
applied_filters (what was actually used, including your key's scope) and
notes (anything to know about the result). Each event has an id, a
one-sentence English description, category, location, sources, importance
and, for ranked searches, why_matched scores.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_events"
  }
}

Input Schema

Name	Required	Description
`sort`	No	Default: relevance when query or keywords are given, else recency
`limit`	No	Results per page, 1-100 (your plan may allow fewer)
`query`	No	What happened, as one English sentence shaped like the stored events: 'In <place>, <who> <did what>, <result>.' Ranks by meaning. Omit to list by filters only
`cursor`	No	The next_cursor value returned with the previous page
`address`	No	Place name(s), e.g. 'Istanbul Kadikoy'; every word must appear in the event's address
`date_to`	No	Last day, inclusive, UTC (YYYY-MM-DD). Default: today
`sources`	No	Source domains, e.g. ['reuters.com']; an event matches if any of its sources is one of them
`keywords`	No	Exact names to match literally (organisation, place), e.g. 'NATO'
`near_lat`	No	Latitude of a point; use with near_lon
`near_lon`	No	Longitude of a point; use with near_lat
`countries`	No	ISO 3166-1 alpha-2 codes, e.g. ['TR', 'DE']; an event matches any of them
`date_from`	No	First day, inclusive, UTC (YYYY-MM-DD). Default: 30 days before date_to
`radius_km`	No	Radius around the point in km, default 10, max 50
`categories`	No	Category slugs (any level: main, type or subtype); an event matches any of them
`min_sources`	No	Minimum number of independent sources
`min_importance`	No	Minimum importance score, 0-1

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description goes further by disclosing pagination (next_cursor), the applied_filters echo (including the API key's scope, which explains silently narrowed results), and a notes field for caveats — meaningful behavior an agent cannot see from annotations alone. Rate-limit behavior is only alluded to via the schema's plan note, not elaborated here.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence with examples, and the second paragraph covers the response shape compactly. Slight redundancy in re-explaining returns despite an output schema, and 'notes (anything to know about the result)' is vague, but 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?

For a 16-parameter, zero-required search tool this covers what an agent needs: what it searches, how to shape a query, pagination, and what comes back. Because an output schema exists, the return-value paragraph is a bonus rather than a necessity; only the absence of guidance on when to prefer a sibling tool leaves a gap.

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% and the schema text is itself detailed (query sentence shape, date defaults, address semantics, sources any-match). The description's 'by meaning, exact names and filters' phrasing maps onto query/keywords/filters but adds no syntax, defaults, or combination rules beyond what the schema already provides, so the baseline 3 applies.

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 ('Search risk events') and then enumerates the covered domains (crime, natural hazards, armed conflict, logistics, protests) with three concrete query examples. An agent can immediately tell this is a broad search tool, distinct from get_event (single fetch), event_stats (aggregates) and list_categories (taxonomy).

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?

The examples ('protests in Istanbul this week', 'stabbings in Lisbon') show intended usage clearly, and the description signals the two search modes: by meaning, exact names, or filters, plus the option to search filters-only. It does not state exclusions or name a sibling to use instead when the agent actually wants a single event or an aggregate, so it stops short of full when/when-not guidance.

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

All AEGIS Events tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?