Warmth Engine Observatory
Server Details
Coordination Intelligence: AI infrastructure coordination dynamics across geopolitical blocs
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 15 of 15 tools scored.
Each tool targets a distinct retrieval operation—actors, blocs, connections, events, threads, topology, etc.—with no functional overlap. Even closely related pairs like get_connections and get_connection_by_id are clearly separated by scope (list vs single).
The majority of tools follow a get_* pattern, but three diverge: query_scp, search_events, and traverse_coordination. While still readable, the mixture of verb prefixes (get, query, search, traverse) and the presence of get_connection_by_id alongside get_connections break a uniform pattern.
15 tools cover the observatory's domain—actors, blocs, events, connections, capability profiles, threads, topology, statistics, and methodology—without bloat. Each tool earns its place, providing a complete surface for programmatic interaction.
The tool surface covers all primary operations expected for a read-only observatory: individual entity retrieval, list/filtering, aggregated views, statistical summaries, and cross-referencing (pivoting, walking). No obvious gaps like missing CRUD operations are relevant, as the domain is observational.
Available Tools
15 toolsget_actorsAInspect
Retrieve whole Sovereign Capability Profile (SCP) actors — each with its designation (PAA / AIK / ACS / Participant), capability score, severance result, and a met/not-met assessment across the seven capability dimensions (D1–D7). 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. Descriptive — recorded status, never inference.
| Name | Required | Description | Default |
|---|---|---|---|
| actor_name | No | Filter by actor name (partial match) | |
| designation | No | Filter by designation: PAA, AIK, ACS, Participant |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the tool is 'descriptive — recorded status, never inference' and explains free vs full tier differences. It could explicitly state read-only behavior, but overall it provides good behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with 5 sentences, each adding distinct value: what it retrieves, usage guidance, filters, tier differences, and clarifying descriptive nature. It is well-structured, though slightly verbose for the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two optional parameters and no output schema, the description covers what data is returned (actor records with fields), filtering, tier differences, and semantic guarantee. It provides enough context for an AI agent to understand the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions filter options and partial match for actor_name, but these are already described in the input schema. It adds no new semantic information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves whole SCP actors with specific fields (designation, capability score, severance result, met/not-met across D1–D7). It explicitly distinguishes from sibling tool `query_scp` by stating what this tool does not do (pivot, compare, dimension-watch).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use to fetch complete actor records' and provides an alternative: 'to pivot one dimension across all actors... use `query_scp`.' It also mentions filtering options, giving clear context for when to use this tool vs siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_blocsAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully carries the behavioral burden. It declares the tool is read-only ('descriptive roster, never inference'), returns complete data, and is a machine mirror. Only missing details like rate limits or data freshness, but for a static register this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long sentence but well-organized with semicolons and dashes. It contains all necessary information without redundancy. Could be slightly more concise, but it's clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and many siblings, the description fully covers what the tool does, what it returns, and how it relates to the sibling. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% (no params). The rule gives a baseline of 4 for zero parameters. The description adds no parameter meaning because none exist, but this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Retrieve' and the resource 'WEO Bloc Membership Register', listing all contained data elements. It distinguishes from sibling 'get_methodology' by stating that category definitions are served elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Served whole and free' indicates no parameters needed. It also tells when not to use this tool ('for category definitions, use get_methodology'). This is excellent differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_capability_linksAInspect
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); the full tier adds qualification_basis, rationale, and note (the deep qualification analysis). 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, so the link-type and attribution distinctions return on both tiers. For the higher-order signatures built from these links, use get_capability_signatures.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | No | Actor code filter: US, CN, EU, FR, GB, IN, JP, KR, NL, TW | |
| event_id | No | Event id filter, e.g. "196" | |
| dimension | No | Dimension code filter: D1–D7 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data structure, including link_type, attribution, entity, and the full tier fields. It also explains how to derive sole-vs-multiple basis. While it doesn't explicitly state rate limits or auth, it provides sufficient behavioral context for the data returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but each sentence adds meaningful detail. It front-loads the main purpose and then elaborates on filter options and data fields. Could be slightly more concise, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return structure comprehensively, including the full tier fields. It also references a sibling tool for related functionality. The tool appears to be a read operation, and the description covers what is needed for an agent to interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value: it clarifies actor codes (noting 'GB' not 'UK'), dimension codes as D1–D7, and provides an example for event_id. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'event↔dimension membership links' for SCP capability dimensions, specifying the exact resource and action. It also distinguishes from the sibling tool get_capability_signatures by noting that tool is for higher-order signatures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides filtering options by actor, dimension, and event_id. It also gives an alternative: 'For the higher-order signatures built from these links, use get_capability_signatures.' This guides the agent on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_capability_signaturesAInspect
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 — plus metadata (the directional-edge inventory and the pre-operational caveat) and the non-signature same-capability clusters. Pass signature_id (e.g. "CS-001") for one. For the underlying event↔dimension membership links, use get_capability_links. A derived overlay over the directional CC graph; served whole and free.
| Name | Required | Description | Default |
|---|---|---|---|
| signature_id | No | Signature id e.g. "CS-001"; omit for all signatures |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that data is precomputed, directional, and 'served whole and free', and describes output components (nodes, legs, metadata, caveats). Does not mention side effects or permissions, but these are less critical for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose first, then output details, parameter usage, sibling reference, summary. Slightly verbose but each sentence adds useful information. Front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, yet description thoroughly explains what the tool returns (signatures with nodes, legs, dimension span, etc.) and mentions metadata and non-signature clusters. Includes sibling tool reference for missing functionality, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents the parameter. The description reiterates 'Omit signature_id for whole set' vs 'Pass signature_id for one', adding minimal new semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and clearly identifies the resource ('precomputed Capability Signatures'), explaining what they are (directional CC chains/hubs). It distinguishes from sibling `get_capability_links` by noting it's a derived overlay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use this tool (retrieve signatures) and explicitly mentions the alternative `get_capability_links` for underlying links. Lacks explicit 'when not to use' statements but gives sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_connection_by_idAInspect
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 | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes | CC identifier (e.g., "CC-06-11-3") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes conditional return behavior (full evidence vs base fields) but does not explicitly state read-only nature, permissions, or error handling. No annotations provided, so description carries burden; adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple single-parameter tool without output schema: covers purpose, when to use, return behavior conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter fully (100%), description adds context like ID format example and usage guidance, enhancing meaning beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Retrieve a single Coordination Connection (CC) by its connection_id'. Distinguishes from sibling tool get_connections by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you have the exact identifier; to list or filter CCs, use get_connections', providing clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_connectionsAInspect
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 | Required | Description | Default |
|---|---|---|---|
| event_id | No | Return only CCs involving this event (as source or target) | |
| confidence | No | Filter by confidence level: CC-V, CC-E, CC-A | |
| connection_type | No | Filter by CC type (1–7) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return fields and filtering behavior well, but does not explicitly state read-only nature or potential side effects. Given it's a retrieval tool, the description is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but somewhat lengthy. It is well-structured, starting with the main action and then detailing filters and output. No superfluous sentences, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description does a good job covering the tool's behavior, including output fields and filtering. It is sufficiently complete for a list retrieval tool, though pagination or limits are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds meaning by clarifying that event_id filters 'as source or target' and lists the confidence values explicitly, enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Coordination Connections (CCs), a specific resource, and distinguishes it from the sibling get_connection_by_id by noting that get_connections returns a list optionally filtered by event, type, or confidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use get_connection_by_id for a single CC, providing a clear alternative. This helps the agent choose the right tool for the task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_coverage_statsAInspect
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, the event-ID range, and the methodology version. No parameters; figures are computed live, so the response always reflects the present database. The secondary-industry breakdown is full-tier only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys that the tool is a live, read-only operation with no side effects. It provides details like 'always reflects the present database' and a note on secondary-industry breakdown, though it omits potential performance or caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a clarifying note; no wasted words. The main action is front-loaded, and the breakdowns are listed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description arguably covers the essential information: live data, no inputs, and a detailed list of statistics. It lacks explicit structure of the response but is sufficient for an intelligent agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds value by confirming zero parameters and explaining the live computation, exceeding the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and clearly identifies the resource as 'corpus statistics' with detailed breakdowns (events, CCs, SCP actors) and dimensions (bloc, tier, domain, etc.), distinguishing it from sibling tools that focus on individual entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'No parameters' and 'figures are computed live,' giving clear context. It lacks explicit when-not-to-use or alternatives, but the specificity and sibling list implicitly guide the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eventAInspect
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 | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Zero-padded event ID (e.g., "06", "141") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses tier-based behavior: free tier returns complete record for sample events but only classification facts for others, full tier returns everything. Also specifies input format. No annotations provided, so description carries full burden and does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences: purpose, usage guidance, and tier behavior. Every sentence adds unique value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 parameter, no output schema), the description comprehensively explains what is retrieved, the tier-dependent behavior, and how to use the tool. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description merely repeats the schema's parameter description without adding new meaning. Baseline of 3 is appropriate as the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Retrieve' and the resource 'one event by ID', and lists the fields returned. Distinguishes from sibling tools by directing to use 'search_events' to find IDs, implying this tool is for when the ID is already known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when you already hold an event ID; to find IDs, use search_events.' Provides guidance on input format (zero-padded string) with examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_stackAInspect
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 Sovereign Capability Profile (SCP) dimension-membership waypoints for the event itself (actor, dimension, link_type, attribution, entity; 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. 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 | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Focal event id e.g. "196" — the event whose stack neighbourhood to assemble |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the derived nature, gating, free tier limitations, and that the three arrays are never merged. It differentiates the types of claims (thread is factual, not a CC). Could mention authorization or rate limits but not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with information but front-loads the purpose. Could be slightly more concise, but every sentence adds value. Remains within acceptable length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given sibling tools and no output schema, the description covers all aspects: what each array contains, the nature of claims, and how it compares to alternatives. It is complete for an AI agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (event_id) with 100% schema coverage. The description adds 'Focal event id e.g. "196"' which is already in the schema. No additional semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assembles the stack journey for one event, returning three specific arrays (coordination, material, capability). It distinguishes itself by naming sibling tools and explaining what they do (get_threads for material alone, traverse_coordination for lineage).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool and when to use alternatives: 'For the material layer alone, use get_threads; for the directed multi-hop coordination lineage between events, use traverse_coordination.' Also implies this is the one-stop for all three layers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_methodologyAInspect
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 | Required | Description | Default |
|---|---|---|---|
| term | Yes | The term to look up (e.g., "CC-V", "T2", "PAA", "ENT-1", "PIET", "Basel Assessment") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the matching algorithm and response for unknown terms, making behavior predictable. Does not discuss side effects or authentication, but since it's a read-only lookup, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Purpose is stated first, followed by use case and behavioral details. Efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter, no output schema, and no annotations, the description is thorough. It explains the return content (definition, section anchor, deep link, version) and the matching strategy, fully equipping the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (parameter description in input schema). The description adds value by listing examples and explaining the matching logic, which goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and resource ('WEO methodology definition'), distinguishes from sibling tools by noting it resolves vocabulary returned by others, and provides examples for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool ('Use to resolve any vocabulary the other tools return') and explains matching behavior (exact-first, then substring). Does not explicitly mention when not to use, 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.
get_threadsAInspect
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 | Required | Description | Default |
|---|---|---|---|
| event_id | No | Event id e.g. "182" (a deployer) or "196" (a producer); omit for the whole thread layer |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that threads are not Coordination Connections, explains the directionality of links, and mentions free tier compatibility. No annotations provided, but description covers behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While informative and front-loaded, the description is somewhat verbose. However, each sentence contributes necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the concept, parameter usage, and differentiation from siblings. Lacks explicit output structure description, but hints at response fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'event_id' is already well-documented in the schema (100% coverage), but the description adds context about its effect on inbound/outbound links and the whole layer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the specific resource 'Infrastructure Threads', and distinguishes it from sibling tools like 'get_event_stack' and 'get_connections'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to pass or omit 'event_id', and directs to a sibling tool for alternative use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topologyAInspect
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 | Required | Description | Default |
|---|---|---|---|
| class | No | Filter nodes by taxonomy class: root | internal | leaf | sibling_only | orphan | |
| cc_type | No | Filter to nodes incident to a CC of this type (1–7) | |
| node_id | No | Node id e.g. "E34"; omit for the whole-graph summary | |
| min_reach | No | Filter to nodes with coordination_reach >= this value |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly describes the tool's behavior: retrieves topology data, two modes, specific metrics returned, filtering options, and mentions an optional 'full tier' layer. While it does not explicitly state read-only, the context implies it, and no destructive side effects are suggested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured: main purpose first, then conditional behavior, then sibling distinctions, then optional filters. Every sentence adds necessary detail. Could be slightly tighter, but overall efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 optional parameters and no output schema, the description is very complete. It covers both modes of operation, lists specific structural metrics, mentions filtering, and notes an extended tier. Minor missing details like error handling or output format, but these are not critical given the tool's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value beyond the schema: explains that omitting node_id returns whole-graph stats, clarifies what class, cc_type, and min_reach filter do, and lists metrics returned per mode. This enriches the agent's understanding beyond bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving a precomputed Coordination Topology (a DAG of parent-child coordination connections). It specifies whole-graph vs. node-specific modes and lists the exact metrics returned, distinguishing it from siblings like traverse_coordination and get_event_stack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with related tools: '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.' This gives the agent clear when-to-use and when-not-to-use guidance. Also explains effect of omitting vs. including node_id and mentions optional filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_scpAInspect
Query the Sovereign Capability Profile (SCP) register by pivoting and comparing — distinct from get_actors, which fetches whole actors. Choose exactly one mode: 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 | Required | Description | Default |
|---|---|---|---|
| watch | No | true → return the dimension_watch register | |
| actors | No | Actor ids e.g. ["US","CN"] → compare those actors across D1–D7 | |
| dimension | No | Dimension id D1–D7 (e.g. "D3") → pivot that dimension across all actors |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description thoroughly discloses behavior: readouts are descriptive and never causal inference, free vs full tier differences, and the nature of the watch register (forward-looking entries). It implies a read-only operation without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with purpose, then sibling differentiation, then mode enumeration. It is slightly lengthy but every sentence adds value. No wasted words, but could be broken into clearer sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains what the readouts contain (met status, headline, evidence details) and the two tiers. It covers all three modes and the usage hint. For a query tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond the schema: it explains the three modes, provides examples, and details what each mode returns and the tier differences. This goes well beyond the parameter descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the SCP register by pivoting and comparing, distinguishes it from get_actors, and explains three distinct modes (dimension, actors, watch). The verb 'query' and resource 'SCP register' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool vs get_actors and instructs to choose exactly one mode. It also mentions that omitting all params gives a usage hint. However, it does not compare to other sibling tools like get_blocs or search_events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_eventsAInspect
Search and filter the WEO event corpus by keyword 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 | Required | Description | Default |
|---|---|---|---|
| bloc | No | Filter by bloc: Western, Eastern, Western-Led, Eastern-Led, Cross-Bloc | |
| tier | No | Filter by tier: 1, 2, or 3 | |
| type | No | Filter by event type: Policy, Infrastructure, Corporate, Coordination | |
| limit | No | Number of results (default 20, max 50) | |
| query | No | Keyword search across event name and description | |
| domain | No | Filter by domain: Technology, Energy/Infrastructure, Security, Trade | |
| industry | No | Filter by primary industry tag |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that results are capped by `limit` (default 20, max 50) and explains the tier differences: free tier withholds deeper assessment on non-sample events. This is good transparency, though it could optionally mention pagination or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured: first sentence states the core function, second provides usage guidance with alternative tool, third explains tier-dependent behavior. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must cover return values. It states 'returns the matching events with their metadata' and explains tier differences affecting returned fields. This is sufficient for a search tool, though a list of typical metadata fields would be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by stating the default value for `limit` (20) and clarifying that `query` searches across event name and description. These details are not in the schema descriptions and aid agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches and filters the WEO event corpus by keyword or classification, specifying the available filters (bloc, tier, domain, event type, primary industry tag). It explicitly distinguishes this tool from the sibling `get_event` tool, which is for retrieving a single event's complete record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use to discover or shortlist events; for a single event's complete record, use `get_event`.' It also explains the tier-dependent behavior (free vs full) and the default/max limit, giving clear when-to-use and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
traverse_coordinationAInspect
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. Optional cc_types restricts edge types, max_depth caps path length, homogeneous_only drops any path crossing a sibling edge.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Traversal mode | |
| source | No | Source node id for mode=path | |
| target | No | Target node id for mode=path | |
| node_id | No | Node id for ancestors | descendants | neighbours | |
| cc_types | No | Edge-type (colour) filter; default = all 7 | |
| max_depth | No | Maximum path length | |
| homogeneous_only | No | true → drop any path crossing a sibling (Type 6/7) edge |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses that lookups are precomputed, explains mode-specific behaviors, describes the output for 'path' mode (paths with CC-type sequence and purity), and notes the effect of homogeneous_only. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, which may be slightly hard to scan, but every sentence adds value. Key information is front-loaded (main action, then modes, then filters). It is efficiently written with no redundancy, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description covers all parameters and their effects, explains the return for 'path' mode, and provides context for when to use each mode versus the sibling. It is complete and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3, but the description adds significant meaning beyond the schema: it explains the purpose of each mode, the effect of cc_types (restricts edge types), max_depth (caps path length), and homogeneous_only (drops paths crossing sibling edges). This greatly helps an agent select and use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool walks the Coordination Topology lineage graph, specifying precomputed lookups over parent→child DAG. It distinguishes from sibling tool 'get_topology' by describing that tool's purpose (structural metrics or whole-graph summary), leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use each mode (path, ancestors, descendants, neighbours) and when to use 'get_topology' instead. It also describes optional filters (cc_types, max_depth, homogeneous_only) and their effects, providing comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!