Skip to main content
Glama

query_signals

Destructive

Query geolocated world event signals with severity and GEOINT scores, filterable by location, date, and category, to identify satellite-collection opportunities.

Instructions

Query geolocated world event signals (Delta Signals: geopolitical, security, disaster, and infrastructure events distilled from global news media, AI-enriched with severity/GEOINT scores and satellite-collection recommendations). Filter by bounding box, date window, and category. Costs 3 token(s) per call, charged to the API key owner's balance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bboxNoBounding box [minLon, minLat, maxLon, maxLat] (WGS84). Omit for worldwide.
dateNoWindow end date, YYYY-MM-DD (UTC). Defaults to today.
daysNoWindow length in days ending on `date`. Defaults to 1.
sortNoResult ordering. Omit for the feed's default ranking. "geoint" ranks by the continuous GEOINT collection priority (intelligence.collection_priority) — an imageability gate times tasking value (severity, urgency, information gain, corroboration, escalation, market) — so imageable, decision-relevant events (e.g. a high-severity escalating strike) rise and non-observable news noise sinks. This is NOT the saturated geoint_score.
limitNoMaximum rows per page. Defaults to 100.
cursorNoOpaque pagination cursor from a previous response's meta.next_cursor.
marketsNoRestrict to signals AI-tagged as exposing these financial markets via a direct physical/supply channel (informational only, not investment advice). Omit for all.
openDataNoKeep only signals with this open-data sufficiency — free imagery is enough vs commercial tasking recommended (intelligence.open_data_sufficiency).
categoriesNoRestrict to these categories. Omit for all.
escalatingNoKeep only signals whose escalation_trend is "escalating".
minSeverityNoKeep only signals with severity_score >= this (0-10).
createdSinceNoDifferential fetch: only signals first enriched at/after this ISO 8601 timestamp.
taskableOnlyNoKeep only signals whose coordinate is search_ready — GEO-READY ONLY: drops country centroids, ADM1 mismatches, reporting-dateline fallbacks and unresolved fixes (intelligence.geo_validation.search_ready). It does NOT imply observable or quality-passed, so not-observable / insufficient-detail / quality-failed signals can still appear. For automated imagery tasking use collectionReadyOnly (or combine with observability:"observable").
updatedSinceNoDifferential fetch: only signals (re)enriched at/after this ISO 8601 timestamp. Ignores the date window. Response signals carry last_updated_at.
observabilityNoKeep only signals with this satellite observability — whether a physical mark is imageable at all (intelligence.satellite_observability).
responseFormatNoPer-signal field detail. "concise" (default) returns the key decision + GEOINT fields (id, date, category, title, location, lat/lng, severity/geoint scores, collection_priority, escalation, market, rs_level/rs_sensor, observability, observability_status, verification_status, geo_status, search_ready, article_count, independent_source_count, information_gain) — cheaper to scan. "detailed" returns the full Signal object (shape per the signals://schema resource).
minInformationGainNoKeep only signals whose intelligence.expected_information_gain >= this (0-1).
collectionReadyOnlyNoSTRICT tasking-candidate filter: search_ready AND observability=observable AND quality.status!=failed AND a concrete collection plan (rs_target + rs_reason present) AND an event coordinate. The safe input set for automated imagery tasking — a superset of every gate taskableOnly alone does not check.
observabilityStatusNo3-state observability filter. Unlike `observability` (binary), this exposes `insufficient_detail` — signals where imageability is unknown (no RS enrichment yet, unresolved location, or an Impossible verdict rescued because the event reads kinetic). `not_observable` = a considered "nothing to image"; neither bucket leaks insufficient_detail.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaYesQuery echo, token charge/balance (meta.tokens), and pagination where applicable.
signalsYes
summaryNoOne-line natural-language summary of the result, ready to relay to a user.
Behavior1/5

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

The description describes a read-only query operation, yet annotations declare destructiveHint=true and readOnlyHint=false. This contradicts the description, which also does not disclose any state-changing or destructive behavior beyond a token cost. The annotation contradiction is severe and unaddressed.

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?

The description is two sentences, front-loaded with the core purpose. The first sentence is dense with the Delta Signals definition but remains informative. The second sentence concisely states filter options and cost. No redundant or filler content.

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

Completeness3/5

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

Given the tool's 19 parameters and an output schema, the description provides a high-level overview and notes cost. It does not explain pagination, use-case prioritization, or return-value structure, but those are covered by the schema and output schema. The annotation contradiction leaves a critical gap, but for the description alone, it is minimally sufficient.

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%, with every parameter richly described in the schema itself. The top-level description only references three filter types (bbox, date, category) that are already documented in the schema. Thus the description adds no semantic value beyond the schema, warranting the baseline score.

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?

The description opens with 'Query geolocated world event signals' — a specific verb+resource that clearly distinguishes from siblings like query_stats and get_world_brief. The parenthetical defining Delta Signals adds context without ambiguity. The filter mention further clarifies the tool's domain.

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 description states 'Filter by bounding box, date window, and category,' offering clear context on how to use the tool. However, it doesn't explicitly state when to use this tool over alternatives or when not to use it. No exclusions or explicit comparative guidance are given.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Off-Nadir-Lab/offnadir-delta-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server