Skip to main content
Glama

Warmth Engine Observatory

by com.warmthengine
OverviewDiscussionsAdmin

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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed1 schema field changed
    • addedInput schema / properties / include_retired
      Added value: +{
+  "description": "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 reconstruct a past state.",
+  "type": "boolean"
+}
  3. First observed

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources