Skip to main content
Glama

Warmth Engine Observatory

by com.warmthengine

get_threads

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
event_idNoEvent id e.g. "182" (a deployer) or "196" (a producer); omit for the whole thread layer

TDQS

A4.7/5.0
Behavior5/5

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

No annotations are present, so the description carries the full burden, and it does so thoroughly. It explains what a thread is and is not, the linkType values (deploys, trains_on, powered_by, fabricated_at), bidirectional traversals, and behavior when event_id is omitted. It even notes pricing ('Free on both tiers').

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

Conciseness4/5

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

The description is dense and long but every sentence adds semantic value for a complex concept. It is well-structured with clear definitions, mode explanations, and an explicit alternative. Slight trimming of the linkType enumeration could improve readability, but no information is wasted.

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

Completeness4/5

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

With no output schema, the description still explains what each link carries, the linkType values, and the global vs per-event behavior. It stops short of describing the exact response shape or pagination, but for a single optional parameter and read-only intent, the agent has enough context to call and interpret the tool confidently.

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% and the schema already provides an example and the omission behavior. The description adds value by explaining how event_id selects inbound vs outbound traversal and by characterizing values like '182' as deployer and '196' as producer, which is meaningful beyond the schema alone.

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

Purpose5/5

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

The description names a specific resource ('Infrastructure Threads'), defines it as the 'factual material-link layer', and differentiates it from Coordination Connections. This lets an agent distinguish the tool from get_connections and get_event_stack 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?

The description gives explicit invocation modes: pass event_id for inbound/outbound links for a single event, or omit it for the whole layer. It also names the sibling alternative get_event_stack for value-chain stacks, making selection guidance unambiguous.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool targets a distinct data slice or operation. For example, `get_actors` retrieves full actor profiles while `query_scp` offers pivoting and comparison; `search_events` finds event IDs and `get_event` retrieves a full record; `get_threads` provides material links separate from `traverse_coordination` for lineage walks. There is no overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent `verb_noun` pattern with underscore separators. Most use `get_` for retrieval, with `query_scp`, `search_events`, and `traverse_coordination` using different verbs that accurately reflect their distinct actions. The naming is predictable and intuitive.

Tool Count5/5

16 tools is well-scoped for the complexity of an observation platform that covers actors, blocs, events, connections, topology, vocabulary, statistics, and material links. Each tool earns its place by covering a necessary query pattern without unnecessary fragmentation.

Completeness5/5

The tool set provides comprehensive coverage of the domain: actor retrieval and querying (profiles, comparisons, watch), bloc membership, event discovery and full records, connection traversal and filtering, structural topology, material links, vocabulary lookups, and summary statistics. No obvious gaps in read access are present.

Resources