Skip to main content
Glama

Warmth Engine Observatory

by com.warmthengine

get_capability_signatures

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
signature_idNoSignature id e.g. "CS-001"; omit for all signatures
include_retiredNoInclude 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 reconstruct a past state.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it excels: it discloses that signatures are never edited in place, that changes retire the whole signature, that active signatures are the default, that `member_links` is authoritative while node fields are denormalized, and that a caveat exists for pre-operational data. This gives the agent a reliable model of side effects, defaults, and data provenance.

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

Conciseness3/5

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

The description is information-dense and technically precise, but it is quite long and some phrasing adds little actionable value, such as 'corroborating structural texture rather than a headline finding' and 'served in full and free.' While the length is defensible for a complex domain, the structure could be tighter and more front-loaded around selection and behavior.

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?

Given no output schema, the description thoroughly enumerates what will be returned: nodes, directional legs, dimension span, attribution, lifecycle fields, metadata, status counts, the pre-operational caveat, and non-signature clusters. It also addresses how to resolve `member_links` via `get_capability_links`, making the tool effectively callable in a broader workflow.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds real interpretive value beyond the schema: it explains the result of omitting `signature_id`, defines retired signatures as frozen whole-state snapshots, clarifies default active-only behavior, and describes how `include_retired` enables reconstruction of past states. This goes well beyond the schema's basic field descriptions.

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 opens with a specific verb ('Retrieve') and a well-defined resource ('precomputed Capability Signatures'), then distinguishes the object from related concepts like Capability Links and directional CC graph structures. It clearly differentiates this tool from siblings such as get_capability_links by positioning this as the signature-level view.

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

Usage Guidelines4/5

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

The description gives explicit usage paths: omit `signature_id` for the full set, pass it for one signature, and pass `include_retired` for retired signatures. It also explicitly routes the agent to `get_capability_links` for underlying membership links, which is an effective alternative. It does not, however, contrast this tool with all nearby structural siblings such as `traverse_coordination` or `get_topology`.

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