Which integrations are available for this server?

Provides tools to check network anomalies (BGP hijacks, leaks) and outage annotations via Cloudflare Radar API.

How do I use global-sentinel-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@global-sentinel-mcp get macro alert for geopolitical risks" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

global-sentinel-mcp

by ykshah1309

Overview Schema Source Related Servers Discussions Admin

Python

Remote

global-sentinel-mcp

An async MCP server unifying prediction markets, global news events, aviation state, and internet-infrastructure telemetry into one alternative-data layer for macro and financial analysis.

PyPI version Python 3.11+ MIT License Publish

Status: Beta — ready for production use; public API may still shift before 1.0.

Why this exists

Alternative data — prediction-market odds, real-time geopolitical event streams, live aviation transponder data, and internet-infrastructure telemetry — is increasingly central to macro and financial analysis. Each source has its own API shape, authentication model, and update cadence, making it tedious to wire them together for every new project.

global-sentinel-mcp closes that gap by wrapping four public data feeds behind a single Model Context Protocol (MCP) interface. An LLM agent can ask probability, event, aviation-state, and internet-telemetry questions in one place, without knowing the upstream API details. It also exposes a composite macro alert tool that fuses news events and outage annotations into one convergence signal with a human-readable explanation.

The server is fully async (httpx.AsyncClient with retry transport), returns typed Pydantic v2 models for every response and error, ships a TTL cache per source to stay within upstream rate limits, and installs in one command over stdio — no web server required.

Related MCP server: pmxt-mcp

Available Tools

Tool	Data Source	What it returns
`get_prediction_odds`	Polymarket	Ranked event odds (probability %, volume, end date) for a query
`get_prediction_event_by_id`	Polymarket	Odds for a specific event id or slug
`lookup_aircraft_state`	OpenSky Network	Latest ADS-B state for a tail number (N-Number) or ICAO24 hex
`convert_nnumber`	— (offline)	Pure-Python FAA N-Number ↔ ICAO24 conversion, no network needed
`get_global_events`	GDELT 2.0	High-impact events for a country, ranked by Goldstein scale
`check_network_anomalies`	Cloudflare Radar	BGP hijacks + leaks and regional outage annotations
`get_macro_alert`	GDELT + Cloudflare	Composite convergence signal with explanation string

Quickstart

1. Install

uvx global-sentinel-mcp

Or install from PyPI:

pip install global-sentinel-mcp

2. Set environment variables (all optional — unset tools degrade gracefully)

# OpenSky — OAuth2 preferred (post-2025 migration), Basic Auth for legacy accounts.
export OPENSKY_CLIENT_ID="your_opensky_client_id"
export OPENSKY_CLIENT_SECRET="your_opensky_client_secret"
# Cloudflare Radar — required for BGP and outage tools.
export CLOUDFLARE_API_TOKEN="your_cf_token"
# Optional.
export LOG_LEVEL="INFO"

3. Run

global-sentinel-mcp

The server speaks MCP JSON-RPC over stdio.

Local development

git clone https://github.com/ykshah1309/global-sentinel-mcp
cd global-sentinel-mcp
uv sync --dev
uv run global-sentinel-mcp        # run the server
uv run pytest tests/ -v           # run the test suite
uv run ruff check src/ tests/     # lint
uv run mypy src/                  # type-check

Claude Desktop configuration

Add to claude_desktop_config.json (see claude_desktop_config.example.json):

{
  "mcpServers": {
    "global-sentinel": {
      "command": "uvx",
      "args": ["global-sentinel-mcp"],
      "env": {
        "OPENSKY_CLIENT_ID": "your_opensky_client_id",
        "OPENSKY_CLIENT_SECRET": "your_opensky_client_secret",
        "CLOUDFLARE_API_TOKEN": "your_cf_token"
      }
    }
  }
}

Cursor configuration

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "global-sentinel": {
      "command": "uvx",
      "args": ["global-sentinel-mcp"],
      "env": {
        "OPENSKY_CLIENT_ID": "your_opensky_client_id",
        "OPENSKY_CLIENT_SECRET": "your_opensky_client_secret",
        "CLOUDFLARE_API_TOKEN": "your_cf_token"
      }
    }
  }
}

Environment Variables

Variable	Required for	Description
`OPENSKY_CLIENT_ID`	aviation (OAuth2, preferred)	OpenSky OAuth2 client id — register free
`OPENSKY_CLIENT_SECRET`	aviation (OAuth2, preferred)	OpenSky OAuth2 client secret
`OPENSKY_USERNAME`	aviation (legacy)	OpenSky Basic Auth username (pre-2025 accounts)
`OPENSKY_PASSWORD`	aviation (legacy)	OpenSky Basic Auth password
`CLOUDFLARE_API_TOKEN`	BGP + outages	Cloudflare API token with Radar read permissions
`LOG_LEVEL`	—	Python log level (DEBUG / INFO / WARNING / ERROR). Default `INFO`.

Polymarket and GDELT tools require no authentication. Anonymous OpenSky is allowed but heavily rate-limited.

Data Sources

Polymarket (Gamma API)

Crowd-sourced prediction market data. Token prices reflect the crowd's estimated probability of future events. No API key required. Events expose outcomes and outcomePrices as JSON-encoded strings — the client parses the "Yes" leg and returns it as probability_pct. Docs

GDELT 2.0

The world's largest open-access global news event database, updated every 15 minutes. Events are coded with actors, event types, Goldstein conflict/cooperation scores, and geographic coordinates. Per publish cycle the server downloads and parses the 5 MB export zip exactly once, then answers all country queries from an in-memory DataFrame cache. Docs

OpenSky Network

Public ADS-B flight tracking from a global network of volunteer receivers. Returns real-time position, altitude, velocity, and on-ground status for any aircraft with a Mode S transponder. Post-2025 the service moved to OAuth2 client-credentials; this server handles token refresh automatically and falls back to Basic Auth (legacy) or anonymous if credentials are absent. Docs

Cloudflare Radar

Internet-infrastructure telemetry from Cloudflare's global network. Covers BGP routing anomalies (/bgp/hijacks/events, /bgp/leaks/events) and regional outage annotations (/annotations/outages, formerly "traffic anomalies", renamed by Cloudflare in 2024). Requires a free Cloudflare API token. Docs

Contributing

See CONTRIBUTING.md for setup instructions, branch naming conventions, testing requirements, and code style guidelines.

License

Available Tools

7 tools

check_network_anomaliesA

Check Cloudflare Radar for BGP and internet-outage anomalies.

Input formats:

2-letter country code (US, CN, IR) → checks BGP hijacks, BGP route leaks, and regional outage annotations for that country.
ASN string (AS15169, AS13335) → checks BGP hijacks and route leaks involving that ASN. Outage annotations require a country and are omitted for ASN-scoped queries.

Requires CLOUDFLARE_API_TOKEN with Radar read permission.

ParametersJSON Schema

Name	Required	Description	Default
`country_or_asn`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description covers behavior: it details different behaviors for country vs ASN inputs and requires CLOUDFLARE_API_TOKEN with Radar read permission. This provides good transparency.

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?

The description is concise and well-structured, using bullet points for input formats. It is efficient and front-loaded.

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?

The description covers the main functionality and authorization. It lacks information about output format or error scenarios, but given the tool's simplicity, it is fairly complete.

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

Parameters5/5

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

The sole parameter 'country_or_asn' is not described in the schema (0% coverage), but the description fully explains its meaning and valid formats (2-letter country code or ASN string).

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 clearly states it checks for BGP and internet-outage anomalies, and explains what each input type checks. It is specific and distinct from sibling tools.

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 explains input formats and what each does, providing clear guidance on when to use the tool. It does not explicitly mention when not to use or alternatives, but the context is clear.

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

convert_nnumberA

Convert between an FAA N-Number and its ICAO24 hex address.

Input detection is automatic: a leading N followed by digits/letters is treated as an N-Number; a 6-character hex string as an ICAO24. Returns both forms plus mode = "n_to_icao" or "icao_to_n". Useful for cross-referencing aviation data sources that use different identifiers.

ParametersJSON Schema

Name	Required	Description	Default
`identifier`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Discloses automatic detection, returns both forms plus 'mode' flag. No annotations provided, so description carries full burden. For a simple conversion, it adequately covers behavior.

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?

Two sentences plus a usage note; no wasted words. Front-loaded with purpose and ends with practical usage context.

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

Completeness5/5

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

Complete for a simple one-parameter tool: explains input format, output fields, and use case. No output schema needed given straightforward return values.

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

Parameters5/5

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

The only parameter 'identifier' is fully explained in description: accepts N-number (N + digits/letters) or ICAO24 (6-char hex). Compensates for 0% schema description coverage.

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 clearly states the function: convert between FAA N-Number and ICAO24 hex address. It specifies the verb 'Convert' and the two identifiers, distinguishing it from sibling tools like lookup_aircraft_state.

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?

Describes automatic input detection based on format (N-prefix vs 6-char hex). Provides use case for cross-referencing aviation data. No explicit exclusions needed given distinct siblings.

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

get_global_eventsA

Fetch recent high-impact GDELT 2.0 events for a country.

GDELT publishes a new global event export every 15 minutes. Events are coded with a Goldstein scale from -10 (destabilizing) to +10 (stabilizing). Pass a 3-letter GDELT country code (e.g. USA, CHN, RUS) or 2-letter FIPS code depending on dataset version.

Results are sorted by Goldstein scale descending and capped at limit. Each event returns actor country codes, Goldstein score, article count, and a source URL.

ParametersJSON Schema

Name	Required	Description	Default
`country_code`	Yes
`min_goldstein_scale`	No
`limit`	No

TDQS

A4.5/5.0

Behavior4/5

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

Discloses that results are sorted by Goldstein scale descending, capped at limit, and returns specific fields. Mentions GDELT's 15-minute update cycle. No annotations, so description carries burden; no destructive behavior implied.

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?

Six sentences across two paragraphs, front-loaded with purpose, all sentences add value: data source, scale, code options, sorting, limits, return fields. No fluff.

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?

No output schema, but description explains return fields (actor country codes, Goldstein score, article count, source URL). Lacks error handling or missing data mentions, but sufficient for intended use.

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

Parameters5/5

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

Schema coverage is 0%, but description fully explains country_code (code format), min_goldstein_scale (threshold with default), and limit (capping). Adds value beyond schema's type info.

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?

Clearly states the tool fetches recent high-impact GDELT 2.0 events for a country, explains the Goldstein scale, and describes output formatting. Distinct from siblings like check_network_anomalies and get_macro_alert.

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?

Provides clear instructions on using country codes (3-letter GDELT or 2-letter FIPS) and explains sorting and capping. Lacks explicit mention of when not to use this tool, but sibling tools are sufficiently different.

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

get_macro_alertA

Composite macro-inflection signal for a region.

Runs three queries concurrently (GDELT events, BGP hijacks, outages) and emits a single signal_score with a one-line explanation of how the number was built. Partial failures are tolerated — if one source errors, the tool still returns the others and records the failure under errors.

Score weighting: |Goldstein| × log(1 + article_count) for each event; outages weighted by cause (government shutdowns dominate). Zero indicates a quiet region — the absence of signal is also information.

ParametersJSON Schema

Name	Required	Description	Default
`region`	Yes

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations, the description fully discloses key behaviors: concurrent queries, partial failure tolerance, error recording, scoring formula, and interpretation of zero. This exceeds the burden of transparency.

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 compact and front-loaded, covering all essential aspects in a single paragraph. Minor improvement could be achieved with bullet points, but it is already concise and well-structured.

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

Completeness5/5

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

Despite no output schema and no annotations, the description provides thorough context: how the tool works, what it returns, failure handling, scoring logic, and the meaning of zero. It is fully sufficient for an agent to understand and invoke the 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?

The schema has zero description coverage for the single 'region' parameter, but the description mentions 'for a region' without specifying format or examples. Given the simplicity of the parameter, the baseline is 3, but more explicit guidance would improve it.

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 clearly states the tool's verb ('composite macro-inflection signal') and resource ('region'), and distinguishes it from siblings by detailing the three concurrent queries. No other sibling tool offers this composite functionality.

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

Usage Guidelines3/5

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

The description implies usage when a concise macro signal is needed, but it lacks explicit guidance on when to use this tool vs. alternatives like get_global_events. No when-not-to-use scenarios are mentioned.

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

get_prediction_event_by_idA

Fetch a single Polymarket event's implied probability by id or slug.

Useful when you already have a Polymarket event identifier (from a prior search, a URL, or an external reference) and want the current odds without re-searching.

ParametersJSON Schema

Name	Required	Description	Default
`event_id`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavior. It states it fetches implied probability, implying a read operation, but does not detail response format or other traits. For a simple fetch tool, this is adequate but not rich.

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?

Two sentences, front-loaded with the core action. Every word is necessary; no redundancy.

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 no output schema and only one parameter, the description is nearly complete: it specifies input (id/slug), output (implied probability), and usage context. The only minor gap is not mentioning the output format explicitly, but it's acceptable for a simple fetch.

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

Parameters4/5

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

The schema coverage is 0% (no description for event_id), but the description clarifies that the parameter accepts both id and slug, adding meaning beyond the schema's type definition.

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

Purpose4/5

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

The description clearly states the action (Fetch) and resource (single Polymarket event's implied probability). It specifies identification by id or slug, which distinguishes it from potential siblings like get_prediction_odds that might use different keys. However, it does not explicitly contrast with siblings.

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 includes a usage scenario: when you already have an identifier and want current odds without re-searching. This provides clear context but does not list alternatives or when not to use.

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

get_prediction_oddsA

Search Polymarket for crowd-sourced probability estimates.

Use this tool when the user asks "what are the odds of X?" for any macro-relevant event — Fed rate decisions, elections, geopolitical outcomes, commodities. Returns up to limit active markets matching the query, each with implied probability (0-100), USDC volume, and end date. Polymarket data is crowd-sourced, not an official forecast.

Example: get_prediction_odds("fed rate cut december", limit=3)

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, description carries full burden. It discloses that it returns up to 'limit' active markets with specific fields and that data is crowd-sourced. Lacks details on error handling, pagination, or rate limits.

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?

Description is concise, well-structured, and front-loaded. Each sentence serves a purpose: purpose, usage, return values, caveat, and example. No wasted words.

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 simple parameters and no output schema, description covers the main return fields and data source. It lacks detail on return format (e.g., is it a list?) and error conditions, but suffices for basic usage.

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

Parameters4/5

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

Schema coverage is 0%, but description adds meaning by explaining 'limit' controls number of results and providing an example usage. It does not explicitly define 'query' but context makes it clear.

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

Purpose4/5

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

The description clearly states it searches Polymarket for probability estimates, specifying the resource (Polymarket) and action (search). It provides a usage scenario (user asks 'what are the odds of X?'), which helps differentiate from siblings like get_prediction_event_by_id, but does not explicitly contrast.

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?

Explicitly says to use when user asks 'what are the odds of X?' for macro events, and notes data is crowd-sourced. However, it does not mention when not to use or compare with alternatives.

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

lookup_aircraft_stateA

Return the latest public ADS-B state vector for a registered aircraft.

Accepts either an FAA N-Number (e.g. N12345, N123AB) or a 6-char ICAO24 hex (e.g. a061d9). N-Numbers are converted in-process first; on failure the FAA public registry is consulted as a fallback.

Returns position (lat/lon), barometric altitude (m), ground speed (m/s), heading (°), on-ground flag, and last-contact timestamp. Requires OPENSKY_CLIENT_ID + OPENSKY_CLIENT_SECRET (OAuth2, preferred) or OPENSKY_USERNAME + OPENSKY_PASSWORD (Basic Auth, legacy).

ParametersJSON Schema

Name	Required	Description	Default
`tail_or_icao`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Discloses authentication requirements (OAuth2 or Basic Auth) and fallback logic for N-number conversion. Without annotations, it covers key behavioral traits, though rate limits or data freshness are not mentioned.

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?

Concise, front-loaded with purpose, and uses structured list for return fields. Every sentence adds value with no redundancy.

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?

Covers inputs, conversion, auth, and output fields adequately. Lacks mention of error handling or data source limitations, but is sufficient for typical use.

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

Parameters4/5

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

With 0% schema coverage, the description compensates by explaining the single parameter's format and providing examples (N12345, a061d9), adding significant meaning 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?

The description clearly states it returns the latest public ADS-B state vector for a registered aircraft, specifying verb and resource. It distinguishes from siblings by being the only tool focused on aircraft state lookup.

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?

Provides clear accepted input types (N-Number or ICAO24 hex) and explains conversion process. However, it does not explicitly state when not to use or mention alternatives among siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.1.1May 30, 2026
- First observedcheck_network_anomalies
- First observedconvert_nnumber
- First observedget_global_events
- First observedget_macro_alert
- First observedget_prediction_event_by_id
- First observedget_prediction_odds
- First observedlookup_aircraft_state

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored 2026-05-30 07:35 across 7 tools

Disambiguation5/5

Each tool targets a distinct domain: network anomalies, aviation identifiers, geopolitical events, composite alerts, and prediction markets. No two tools perform overlapping functions, so agents can easily distinguish them.

Naming Consistency4/5

All tool names use snake_case with descriptive verbs like 'check_', 'convert_', 'get_', and 'lookup_'. While different verbs are used, they are appropriate to each action and follow a predictable pattern, with only minor variation.

Tool Count5/5

With 7 tools, the set is well-scoped for a global monitoring server. Each tool provides a specific, non-redundant capability, and the count is manageable for an agent to navigate without being overwhelming or sparse.

Completeness3/5

The tool surface covers network anomalies, aviation, geopolitical events, and prediction markets, but lacks some expected features like news search or natural disaster monitoring. For a 'sentinel' purpose, there are notable gaps, though core workflows are supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

pronto-stream A
io.github.nmxmxh
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
Agent Orchestration Cryptocurrency Finance
151
HYPERneobroker.com A
com.hyperneobroker.mcp
Live prices, perps, prediction markets and a paper trading desk over one MCP.
Finance Cryptocurrency
371
midasflow-mcp-quickstart A
io.github.midasflowai-lab
Agent-native crypto market-data over MCP+REST: order flow, whales, liquidations, calibrated scores
Cryptocurrency Finance
142
Reasoning Commons
io.github.chenyuan35
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
AI & Machine Learning Knowledge & Memory Autonomous Agents
2

Related MCP Servers

market-data-mcp
SmashToes
-
license
Not graded
quality
Not graded
maintenance
Real-time financial market data MCP server. Stocks, crypto, technicals, sentiment, FDA calendar. No API keys required.
Updated 7 months ago (2026-02-15 04:09 UTC)
-
pmxt-mcpofficial
Finance Autonomous Agents Blockchain
pmxt-dev
A
license
C
quality
B
maintenance
MCP server that provides a unified prediction market API for multiple venues like Polymarket and Kalshi, allowing AI agents to discover markets, fetch order books, and execute trades through a single interface.
Updated 2 months ago (2026-07-18 01:45 UTC)
32
36
8
MIT
BrunoSan AI News MCP Server
Search Research & Data
DowellUG
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that exposes real-time AI news intelligence to AI agents and MCP-compatible clients, with 9 deterministic tools for search, trending, signals, and risk analysis.
Updated 4 months ago (2026-05-03 19:09 UTC)
Apache 2.0
polyrouter-mcp
Finance Web3 & Decentralized Tech
fieldviolence
A
license
Not graded
quality
C
maintenance
MCP server for querying and optionally trading across prediction markets (Polymarket, Kalshi, Limitless, Manifold) through a unified API.
Updated 8 months ago (2026-01-11 22:06 UTC)
31
MIT

global-sentinel-mcp

Why this exists

Available Tools

Quickstart

1. Install

2. Set environment variables (all optional — unset tools degrade gracefully)

3. Run

Local development

Claude Desktop configuration

Cursor configuration

Environment Variables

Data Sources

Polymarket (Gamma API)

GDELT 2.0

OpenSky Network

Cloudflare Radar

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

pmxt-mcpofficial