Skip to main content
Glama
Sign In

Warmth Engine Observatory

by com.warmthengine
OverviewDiscussionsAdmin

Get Coordination Topology

get_topology
Read-onlyIdempotent

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).

Input Schema

NameRequiredDescriptionDefault
classNoFilter nodes by taxonomy class: root | internal | leaf | sibling_only | orphan
cc_typeNoFilter to nodes incident to a backbone (parent→child) edge of this type (1–7)
node_idNoNode id e.g. "E34"; omit for the whole-graph summary
min_reachNoFilter to nodes with coordination_reach >= this value

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / cc_type / enum
      Added value: +[
+  1,
+  2,
+  3,
+  4,
+  5,
+  6,
+  7
+]
    • removedInput schema / properties / cc_type / maximum
      Removed value: -9007199254740991
    • removedInput schema / properties / cc_type / minimum
      Removed value: --9007199254740991
    • changedInput schema / properties / cc_type / type
      Previous value: -"integer"New value: +"number"
    • addedInput schema / properties / class / enum
      Added value: +[
+  "root",
+  "internal",
+  "leaf",
+  "sibling_only",
+  "orphan"
+]
  2. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed1 schema field changed
    • changedInput schema / properties / cc_type / description
      Previous value: -"Filter to nodes incident to a CC of this type (1–7)"New value: +"Filter to nodes incident to a backbone (parent→child) edge of this type (1–7)"
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds substantive context beyond that — the concrete statistics returned, the filter behavior, and the note that 'the full tier adds the held analyst layer', which hints at tier-dependent results. It does not cover pagination or response size limits, so it falls short of a 5.

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

Conciseness4/5

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

Dense but well-structured, with the core purpose and the omit/pass branching front-loaded ahead of the alternative-tool routing and the tier note. It is longer than strictly necessary — the enumeration of per-node metrics could be trimmed — but nearly every sentence carries routing or semantic value.

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

Completeness5/5

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

With no output schema, the description correctly carries the burden of describing return content, covering both the whole-graph summary and the per-node metric list, and it clarifies filter effects. Nothing essential for correct invocation appears to be missing.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the description adds real meaning beyond the schema: the semantics of omitting node_id (whole-graph statistics) versus supplying it (per-node structural metrics), plus the enumerable metric set per node and per-graph. The class/cc_type/min_reach filters are grouped and explained as node-matching filters.

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

Purpose5/5

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

States a specific verb and resource ('Retrieve the precomputed Coordination Topology') and immediately defines the underlying structure (structural lineage layer over the parent→child Coordination Connection DAG). It differentiates itself from siblings by name (traverse_coordination, get_event_stack), so an agent can pick it without opening schemas.

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

Usage Guidelines5/5

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

Explicit branching guidance: omit node_id for whole-graph stats, pass node_id (with example 'E34') for single-node metrics. It also names two alternative tools and the exact conditions under which to prefer them, leaving nothing to inference.

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

All Warmth Engine Observatory toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources