Warmth Engine Observatory
REMOTE · WARMTHENGINE.COM · SCANNED SEP 26
Coordination Intelligence: AI infrastructure coordination dynamics across geopolitical blocs
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security46
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 18 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS check failed: the endpoint is reachable over plaintext HTTP. See how to fix → View diagnostics → Fail
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability77
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 5386 tokens (~283/item across 19 items; 18 tools + 1 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 18 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 20 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Warmth Engine Observatory MCP server?
Warmth Engine Observatory is a hosted endpoint at https://warmthengine.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · warmthengine.com
claude mcp add --transport http com-warmthengine-observatory 'https://warmthengine.com/mcp'
{
"mcpServers": {
"com-warmthengine-observatory": {
"url": "https://warmthengine.com/mcp"
}
}
} {
"servers": {
"com-warmthengine-observatory": {
"type": "http",
"url": "https://warmthengine.com/mcp"
}
}
} [mcp_servers.com-warmthengine-observatory] url = "https://warmthengine.com/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-warmthengine-observatory": {
"type": "remote",
"url": "https://warmthengine.com/mcp",
"enabled": true
}
}
} openclaw mcp add com-warmthengine-observatory --url 'https://warmthengine.com/mcp' --transport streamable-http
mcp_servers:
com-warmthengine-observatory:
url: "https://warmthengine.com/mcp" {
"McpServers": {
"com-warmthengine-observatory": {
"Transport": "http",
"Url": "https://warmthengine.com/mcp"
}
}
} assistant mcp add com-warmthengine-observatory -t streamable-http -u 'https://warmthengine.com/mcp'
{
"mcpServers": {
"com-warmthengine-observatory": {
"type": "http",
"url": "https://warmthengine.com/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 26 Sept 26 0
- Server version: 1.24.1 → 1.25.0 functional
- 25 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 23 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Schema quality: 4872 → 5386 ▼ functional
- Server version: 1.23.0 → 1.24.1 functional
- New tool “get_commitments” functional
- 22 Sept 26 0
- Server version: 1.22.2 → 1.23.0 functional
- 17 Sept 26 0
- Server version: 1.22.1 → 1.22.2 functional
- 6 Sept 26 0
- Server version: 1.22.0 → 1.22.1 functional
- 1 Sept 26 0
- Server version: 1.21.0 → 1.22.0 functional
- 30 Aug 26 −1
- Tool “get_actors” rewrote its description, which is the text the model reads security
- Tool “get_capability_links” rewrote its description, which is the text the model reads security
- Tool “get_capability_signatures” rewrote its description, which is the text the model reads security
- Tool “get_coverage_stats” rewrote its description, which is the text the model reads security
- Tool “get_event_stack” rewrote its description, which is the text the model reads security
- Schema quality: 243 → 270 ▼ functional
- Server version: 1.19.1 → 1.21.0 functional
- “get_capability_links” added an optional parameter “include_retired” cosmetic
- “get_capability_signatures” added an optional parameter “include_retired” cosmetic
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 26 Sept 2026 · Probed https://warmthengine.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=warmthengine.com | CN=YE1,O=Let's Encrypt,C=US | 7 Sept 2026 | 6 Dec 2026 | ECDSA 256 | ECDSA-SHA384 | 6b057351c8d770b8c9990e9afeda04cb04a |
| SANs: *.warmthengine.com, warmthengine.com | ||||||
| CN=YE1,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 5ddd70dd31f801c85c186a7a04b80afe |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of warmthengine.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| warmthengine.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://warmthengine.com/mcp | Verified | 200 | |
| http (plaintext) | http://warmthengine.com/mcp | Served over HTTP | 200 |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
get_actors ~302
Retrieve whole Sovereign Capability Profile (SCP) actors — each with its designation (PAA / AIK / ACS / Participant), capability score, severance result, `assessed` (the register month, YYYY-MM, the profile was assessed in), a met/not-met assessment across the seven capability dimensions (D1–D7), and `energy_context`. Use to fetch complete actor records; to pivot one dimension across all actors, compare actors side by side, or read the dimension-watch register, use `query_scp`. Filter by designation or actor name. Free tier returns each dimension's met status and recorded headline (and the US sample in full); full tier adds the per-dimension constraint, qualification, and sources. `energy_context` carries installed generation capacity from the U.S. Energy Information Administration and annual electricity generation from the energy think tank Ember, served in full on both tiers: external reference data outside the WEO analytical stack, national totals, dated observations reported as published, accompanying the profiles but forming no part of them. Descriptive — recorded status, never inference.
| Name | Type | Req | Description |
|---|---|---|---|
| actor_name | string | – | Filter by actor code (ISO 3166-1 alpha-2, exact, e.g. "CN") or name (partial match, e.g. "China"). Named `actor` in `get_capability_links`. |
| designation | string | – | Filter by designation: PAA, AIK, ACS, Participant |
No output schema declared.
No examples provided.
get_blocs ~102
Retrieve the WEO Bloc Membership Register — every nation in the register with its bloc assignment and universal membership category (Core / Integrated / Engaged / Peripheral / Non-Aligned), its key evidence and source URLs, plus document metadata and sectioned provenance (snapshot history, changelog, pre-register decisions). Served whole and free — the machine mirror of the public blocs register. A descriptive roster, never inference; the category definitions themselves are served by `get_methodology`.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_capability_links ~565
Retrieve the event↔dimension membership links — which events qualify or contribute to each actor's Sovereign Capability Profile (SCP) capability dimensions. Filter by `actor` (e.g. "US", "CN", "GB" — note GB, not UK), `dimension` (D1–D7), or `event_id`. Each link carries its `link_type` (`qualifying_contributor` = establishes the dimension vs `capability_area` = contributes to it), `attribution` (specific | general), and `entity` (the named asset, on qualifying links only); its identity and lifecycle — `link_id` (the stable handle, CL-{ACTOR}-{Dn}-{eventID}.{sequence}), `created`, `scp_register_version` (the register cycle it was assessed in), `assessed_under` (the methodology version in force at that assessment, which may be older than the dataset's current one), `status`, and on retired links `status_changed`; and at full tier `qualification_basis`, `rationale` and `note` (the deep qualification analysis), `status_reason` (the assessed reasoning for a retirement), and `provenance` (construction-cohort marker). Sole-vs-multiple basis is derivable by counting `qualifying_contributor` links per actor×dimension (1 = sole; >1 = one of several) — links are never flattened to `qualifies:yes/no`. Active links are returned by default; retired links are never restored, and a relationship assessed afresh enters as a new link at the next sequence. Pass `include_retired` to receive the archive alongside the active links. The response carries a metadata block — totals by type, per-actor and per-dimension distributions, active/retired `status_counts`, met-dimension coverage figures, and the dataset's generation date and revision history — identical on both tiers; `last_updated` dates the most recent revision. For the higher-order signatures built from these links, use `get_capability_signatures`.
| Name | Type | Req | Description |
|---|---|---|---|
| actor | string | – | Actor code filter (ISO 3166-1 alpha-2; EU for the European Union): US, CN, EU, FR, GB, IN, JP, KR, NL, SA, TW. Named `actor_name` in `get_actors`. |
| dimension | string | – | Dimension code filter: D1–D7 |
| event_id | string | – | Event id filter, e.g. "196" |
| include_retired | boolean | – | Include retired links alongside active ones (default false — active only). Retired links are frozen snapshots of links that no longer qualify; use this to reconstruct a past state, not to read curren… |
No output schema declared.
No examples provided.
get_capability_signatures ~410
Retrieve the precomputed Capability Signatures — directional Coordination Connection (CC) chains or hubs (connection types 1/3/4/5) whose member events span two or more Sovereign Capability Profile (SCP) dimensions, surfaced as corroborating structural texture rather than a headline finding. Omit `signature_id` for the whole set — each signature with its nodes, directional legs (from/to + connection type), dimension span, attribution profile, and narrative; its `member_links`, the explicit list of Capability Link `link_id`s its nodes correspond to; and its own lifecycle fields — `created`, `scp_register_version`, `assessed_under`, `status` — plus metadata (the directional-edge inventory, the active/retired `status_counts`, and the pre-operational caveat) and the non-signature same-capability clusters. Pass `signature_id` (e.g. "CS-001") for one. A signature is never edited in place: a change to its member set retires it whole, and a still-qualifying structure re-enters as a new signature. Active signatures are returned by default; pass `include_retired` to receive retired signatures alongside. `member_links` is the authoritative reference into the membership layer: the node fields are denormalised for rendering and are subordinate to it, so resolve a `link_id` through `get_capability_links` for that node's current status and full detail. For the underlying event↔dimension membership links, use `get_capability_links`. A derived overlay over the directional CC graph; served in full and free, lifecycle fields included.
| Name | Type | Req | Description |
|---|---|---|---|
| include_retired | boolean | – | Include retired signatures alongside active ones (default false — active only). A retired signature is the frozen whole-state snapshot of a structure that changed or ceased to qualify; use this to re… |
| signature_id | string | – | Signature id e.g. "CS-001"; omit for all signatures |
No output schema declared.
No examples provided.
get_commitments ~514
Retrieve the Compute Commitment Register — verified commitments of computing capacity by named actors to societal challenges, one record per instrument, quantities as published, never summed. Returns the challenge table (documents counted once per challenge touched; Committed and Allocated counts), the actor table, records with commitment, delivery and corroborating evidence, the Challenge List Reference, and `definitions` (each register term's defining sentence from the published working note, deep-linked). The register touches events only through Challenge Attributions — for an attributed event use `get_event`; for sovereign capability use `query_scp`; for coordination metrics use `get_metrics`. Pass `view` as `table` (default), `actors`, `records` or `challenges`; filter with `challenge`, `actor_id`, `actor_type`, `band`, `status`, `ai_compute` or `standing`; `record_id` returns one record in full, line items included; `include_history` returns the append-only observation series. Figures are dated observations within a Challenge List epoch — floors of located disclosure, never measures of activity; status stays `pre_operational` until the register's stated conditions are met. Served in full on both tiers.
| Name | Type | Req | Description |
|---|---|---|---|
| actor_id | string | – | Filter to one actor of record by register actor id, e.g. "CCR-ACT-0001". |
| actor_type | string | – | Filter records by actor type (Register Standard vocabulary). |
| ai_compute | string | – | Filter by whether the instrument states the capacity is for AI. |
| band | string | – | Filter by band: A grant or credit programme; B allocation on a named system; C sovereign or multilateral infrastructure; D commercial or philanthropic supply. |
| challenge | string | – | Filter to records with a line item under this challenge (case-insensitive substring; published or sub-threshold). |
| include_history | boolean | – | Return every observation in each series instead of the latest only (default false). |
| record_id | string | – | Return one record in full, line items included, e.g. "CCR-0004". Overrides `view`. |
| standing | string | – | Filter to records with at least one line item of that standing. |
| status | string | – | Filter by record status. |
| view | string | – | `table` (default): the challenge table with the sub-threshold table, transparency line and concentration. `actors`: the actor table. `records`: every live record without line items. `challenges`: the… |
No output schema declared.
No examples provided.
get_connection_by_id ~106
Retrieve a single Coordination Connection (CC) by its `connection_id` (e.g. "CC-06-11-3"). Use when you have the exact identifier; to list or filter CCs, use `get_connections`. Returns the CC with full evidence on the full tier — or when an endpoint is a sample event — and the base fields only otherwise.
| Name | Type | Req | Description |
|---|---|---|---|
| connection_id | string | yes | CC identifier (e.g., "CC-06-11-3") |
No output schema declared.
No examples provided.
get_connections ~174
Retrieve Coordination Connections (CCs) — the typed, directional relationships WEO records between events — optionally filtered by event (as source or target), type (1–7), or confidence (CC-V / CC-E / CC-A). For a single CC by its identifier, use `get_connection_by_id`. Each CC carries its id, source/target event IDs, type name + number, confidence, and direction; full tier — and either tier when an endpoint is a sample event — adds the evidence summary, evidence detail, and verification history.
| Name | Type | Req | Description |
|---|---|---|---|
| confidence | string | – | Filter by confidence level: CC-V, CC-E, CC-A |
| connection_type | integer | – | Filter by CC type (1–7) |
| event_id | string | – | Return only CCs involving this event (as source or target) |
No output schema declared.
No examples provided.
get_contribution ~184
Look up WEO Contribution Architecture vocabulary — the contributor programme's terms, credit classes, and governance provisions (e.g. "Delta Credit", "Founding Observer", "Observer Network", "rate card", "malinformation"). Returns the term's context, its section anchor, and a deep link into the self-hosted CA edition. Omit `term` for programme status: phase, activation criterion, current corpus size, and enquiry address. Use to resolve participation vocabulary — the Contribution Architecture governs participation, whilst the Methodology Manual (`get_methodology`) governs what qualifies. Matching is exact-first, then substring; an unknown term returns a sample of available terms. Served in full on both tiers.
| Name | Type | Req | Description |
|---|---|---|---|
| term | string | – | The CA term to look up (e.g., "Delta Credit", "Founding Observer", "membership facts"). Omit for programme overview. |
No output schema declared.
No examples provided.
get_coverage_stats ~173
Retrieve the current corpus statistics — live counts and distributions of events, Coordination Connections (CCs), and Sovereign Capability Profile actors across bloc, tier, domain, event type, primary industry, CC type, confidence, and designation, plus Environmental Nexus Tag (ENT) statistics with the Warmth Engine Ratio, counts of the derived layers — Infrastructure Threads, Capability Links with their type split, and Capability Signatures — the event-ID range, and the methodology version. Capability Link and Capability Signature counts are of active records only: retired records are excluded so the figures describe present coverage rather than everything ever assessed, with the active/retired splits published in the two capability tools' metadata. No parameters; figures are computed live, so the response always reflects the present database. The secondary-industry breakdown is full-tier only.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_event ~128
Retrieve one event by ID — classification, assessment, sources, industry tags, Environmental Nexus Tags (ENTs), bloc analysis, and tier rationale. Use when you already hold an event ID; to find IDs, use `search_events`. Pass `event_id` as the zero-padded string (e.g. "06", "141"). Free tier returns the complete record for sample events and the classification facts for all others (deeper assessment and evidence withheld); full tier returns every field.
| Name | Type | Req | Description |
|---|---|---|---|
| event_id | string | yes | Zero-padded event ID (e.g., "06", "141") |
No output schema declared.
No examples provided.
get_event_stack ~365
Assemble the stack journey for one event — its kind-labelled value-chain neighbourhood at depth 1, the same composition the Atlas renders, in one call. Returns three separate arrays, never merged: `coordination` — the event's own Coordination Connections (CCs), all seven connection types, directed (types 1/3/4/5) and bidirectional/sibling (types 2/6/7) alike; each carries type/confidence/direction, plus evidence at full tier; `material` — the event's own Infrastructure-Thread edges, one per source→target pair, each with its sourced asset facts (`linkType` + asset + naming field); `capability` — the active Sovereign Capability Profile (SCP) dimension-membership waypoints for the event itself (actor, dimension, link_type, attribution, entity, and the link's `link_id` and lifecycle fields; plus qualification_basis/rationale/note at full tier). The three are different kinds of claim: a thread is a factual asset match, not a CC, and is never rendered as one. The capability array carries active links only and takes no parameter to widen it — a stack is the event's neighbourhood as the corpus now stands; for retired memberships, use `get_capability_links` with `include_retired`. A derived view over the existing connections, threads, and capability links — each substrate keeps its own gating, and the free tier leaks no paid fields. For the material layer alone, use `get_threads`; for the directed multi-hop coordination lineage between events, use `traverse_coordination`. Pass `event_id`.
| Name | Type | Req | Description |
|---|---|---|---|
| event_id | string | yes | Focal event id e.g. "196" — the event whose stack neighbourhood to assemble |
No output schema declared.
No examples provided.
get_methodology ~151
Look up the WEO methodology definition for any platform-specific term, field, or concept (e.g. "CC-V", "T2", "PAA", "ENT-1", "PIET"). Returns the term's definition, its section anchor, a deep link to that section of the published methodology, and the methodology version. Use to resolve any vocabulary the other tools return. Pass `term`; matching is exact-first, then substring, and an unknown term returns a sample of available terms.
| Name | Type | Req | Description |
|---|---|---|---|
| term | string | yes | The term to look up (e.g., "CC-V", "T2", "PAA", "ENT-1", "PIET", "Basel Assessment") |
No output schema declared.
No examples provided.
get_metrics ~294
Retrieve the WEO quantitative coordination metrics — dated observations of the documented connection network computed under Towards Coordination Science (TCS). Returns Cross-Sector Transmission Frequency (CSTF) with its permutation null model, the cross-sector transmission matrix (sparse non-zero cells plus the fixed 11-category row order), Framework Family Density, Cross-Bloc Connection Frequency, and Connection Growth Rate. For live corpus counts and distributions, use `get_coverage_stats` — metrics here are derived, dated observations, never live recomputations. Omit `metric` for all of them; set `include_history` for the full append-only series rather than the latest observation. Pre-operational: the corpus has not reached operational threshold, so every value is a dated observation of the documented record as constructed, not a measurement of the real-world coordination landscape. Each metric carries its own `status` — `published` metrics are surfaced on the platform; `pre_operational` ones are recorded but not publication-grade; `insufficient_corpus` ones are blocked. Values are comparable only within a `taxonomy` epoch. Served in full on both tiers.
| Name | Type | Req | Description |
|---|---|---|---|
| include_history | boolean | – | Return the full append-only observation series instead of the latest observation only (default false). |
| metric | string | – | Single metric key: cstf, transmission_matrix, ffd, cbcf, or cgr. Omit for all metrics. |
No output schema declared.
No examples provided.
get_threads ~216
Retrieve Infrastructure Threads — the factual material-link layer recording where the same named AI hardware asset (chip / GPU / NPU / custom ASIC) appears as a documented fact in two events. A thread is not a Coordination Connection: no connection type, no confidence grade — either the asset match is verified or it isn't. Pass `event_id` for that event's linked events in both directions: outbound = assets this event deploys or trains on, each linking to its producer event; inbound = events that use this event's asset. Each link carries the sourced claim (`linkType` ∈ deploys | trains_on | powered_by | fabricated_at, plus the asset) and the host-event field that names it. Omit `event_id` for the whole layer. For one event's value-chain stack, use `get_event_stack`. Free on both tiers.
| Name | Type | Req | Description |
|---|---|---|---|
| event_id | string | – | Event id e.g. "182" (a deployer) or "196" (a producer); omit for the whole thread layer |
No output schema declared.
No examples provided.
get_topology ~284
Retrieve the precomputed Coordination Topology — the structural lineage layer over the parent→child Coordination Connection graph (a DAG). Omit `node_id` for whole-graph network statistics (taxonomy-class counts, roots, multi-parent nodes, dominant roots by coordination reach, weakly-connected components). Pass `node_id` (e.g. "E34") for one node's structural metrics: generational depth (min/max/all-paths), coordination reach, directed betweenness, path diversity, fan-in/out, taxonomy class, component id. For the actual paths between nodes or up/down a lineage use `traverse_coordination`; for one event's value-chain stack use `get_event_stack`. Optional `class` / `cc_type` / `min_reach` filters return matching nodes. The full tier adds the held analyst layer (chain participation, curated orphan/sibling and named-feature sets).
| Name | Type | Req | Description |
|---|---|---|---|
| cc_type | integer | – | Filter to nodes incident to a backbone (parent→child) edge of this type (1–7) |
| class | string | – | Filter nodes by taxonomy class: root | internal | leaf | sibling_only | orphan |
| min_reach | integer | – | Filter to nodes with coordination_reach >= this value |
| node_id | string | – | Node id e.g. "E34"; omit for the whole-graph summary |
No output schema declared.
No examples provided.
query_scp ~289
Query the Sovereign Capability Profile (SCP) register by pivoting and comparing — distinct from `get_actors`, which fetches whole actors and is where `energy_context` is served; it is not returned here. Pass exactly one of: `dimension` (e.g. "D3") pivots that one dimension across every actor (each actor's met status and recorded headline, on what basis); `actors` (e.g. ["US","CN"]) lays those actors side by side across all seven dimensions (D1–D7); `watch:true` returns the `dimension_watch` register (forward-looking entries: actor, dimension, current vs expected_change, trigger, timeline). Readouts are descriptive — recorded status and fields, never causal inference. Free tier carries `met` + the headline for all actors and the US sample in full; the full tier adds the per-dimension evidence (constraint, qualification, sources, and `escalation_trigger` where recorded). Omit all three params for a usage hint.
| Name | Type | Req | Description |
|---|---|---|---|
| actors | array | – | Actor ids e.g. ["US","CN"] → compare those actors across D1–D7 |
| dimension | string | – | Dimension id D1–D7 (e.g. "D3") → pivot that dimension across all actors |
| watch | boolean | – | true → return the dimension_watch register |
No output schema declared.
No examples provided.
search_events ~242
Search and filter the WEO event corpus by `query` text or classification (bloc, tier, domain, event type, primary industry tag); returns the matching events with their metadata, capped by `limit` (default 20, max 50). Use to discover or shortlist events; for a single event's complete record, use `get_event`. Free tier returns the classification facts with the deeper assessment and evidence withheld on non-sample events; full tier — and sample events on either tier — return every field.
| Name | Type | Req | Description |
|---|---|---|---|
| bloc | string | – | Filter by bloc: Western, Eastern, Western-Led, Eastern-Led, Cross-Bloc |
| domain | string | – | Filter by domain: Technology, Energy/Infrastructure, Security, Trade |
| industry | string | – | Filter by primary industry tag |
| limit | integer | – | Number of results (default 20, max 50) |
| query | string | – | Free-text search across event name and description |
| tier | integer | – | Filter by tier: 1, 2, or 3 |
| type | string | – | Filter by event type: Policy, Infrastructure, Corporate, Coordination |
No output schema declared.
No examples provided.
traverse_coordination ~425
Walk the Coordination Topology lineage graph (precomputed lookups over the parent→child Coordination Connection DAG). `mode="path"` returns every path between `source` and `target`, each with its CC-type (connection-type) sequence and whether it is pure lineage (homogeneous) or crosses a sibling/bidirectional edge; `mode="ancestors"`/`"descendants"` return the nodes reachable up/down the hierarchy; `mode="neighbours"` returns direct parents and children. For a node's structural metrics or the whole-graph summary rather than walks, use `get_topology`. `cc_types` (connection-type filter) and `max_depth` apply to `path` AND to the `ancestors`/`descendants`/`neighbours` adjacency walks — supplying either runs a bounded typed walk over the backbone edges. `homogeneous_only` is `path`-only (drops any path crossing a sibling edge); sent to an adjacency mode it is returned in `ignored_params`. A bare numeric `node_id` missing the `E` prefix is resolved (the canonical form is echoed as `resolved_node_id`); a node that exists but carries no backbone edges is reported as such rather than as unknown.
| Name | Type | Req | Description |
|---|---|---|---|
| cc_types | array | – | Edge-type (connection-type) filter, applied to path and adjacency walks; default = all types |
| homogeneous_only | boolean | – | mode=path only — true → drop any path crossing a sibling (Type 6/7) edge; ignored (and echoed in ignored_params) on adjacency modes |
| max_depth | integer | – | Maximum walk depth — path length in mode=path, hop count from node_id in the adjacency modes |
| mode | string | yes | Traversal mode |
| node_id | string | – | Node id for ancestors | descendants | neighbours (e.g. "E93"; a bare "93" is resolved) |
| source | string | – | Source node id for mode=path |
| target | string | – | Target node id for mode=path |
No output schema declared.
No examples provided.
What is the Warmth Engine Observatory MCP server?
Warmth Engine Observatory is an MCP server listed in the public MCP registry as com.warmthengine/observatory. Coordination Intelligence: AI infrastructure coordination dynamics across geopolitical blocs. This page covers its hosted endpoint (https://warmthengine.com/mcp).
Is the Warmth Engine Observatory MCP server safe to use?
Warmth Engine Observatory scores 74 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Warmth Engine Observatory MCP server expose?
Warmth Engine Observatory exposes 18 tools: search_events, get_event, get_connections, get_actors, get_coverage_stats, and 13 more. Their descriptions and schemas cost roughly 4,924 tokens of context every time the server is loaded.
Does the Warmth Engine Observatory MCP server require authentication?
No. We connected to Warmth Engine Observatory without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the Warmth Engine Observatory MCP server still maintained?
Warmth Engine Observatory is still listed as active in the MCP registry. We last reached this channel on 26 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.