Skip to main content
Glama
Sign In

Warmth Engine Observatory

by com.warmthengine
OverviewDiscussionsAdmin

Get Capability Links

get_capability_links
Read-onlyIdempotent

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); its identity and lifecycle — link_id (the stable handle, CL-{ACTOR}-{Dn}-{eventID}.{sequence}), created, scp_register_version (the register cycle it was assessed in), assessed_under (the methodology version in force at that assessment, which may be older than the dataset's current one), status, and on retired links status_changed; and at full tier qualification_basis, rationale and note (the deep qualification analysis), status_reason (the assessed reasoning for a retirement), and provenance (construction-cohort marker). 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. Active links are returned by default; retired links are never restored, and a relationship assessed afresh enters as a new link at the next sequence. Pass include_retired to receive the archive alongside the active links. The response carries a metadata block — totals by type, per-actor and per-dimension distributions, active/retired status_counts, met-dimension coverage figures, and the dataset's generation date and revision history — identical on both tiers; last_updated dates the most recent revision. For the higher-order signatures built from these links, use get_capability_signatures.

Input Schema

NameRequiredDescriptionDefault
actorNoActor code filter: a Sovereign Capability Profile register code (ISO 3166-1 alpha-2; EU for the European Union); `get_actors` lists the register. Named `actor_name` in `get_actors`.
event_idNoEvent id filter, e.g. "196"
dimensionNoDimension code filter: D1–D7
include_retiredNoInclude retired links alongside active ones (default false — active only). Retired links are frozen snapshots of links that no longer qualify; use this to reconstruct a past state, not to read current membership.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / dimension / enum
      Added value: +[
+  "D1",
+  "D2",
+  "D3",
+  "D4",
+  "D5",
+  "D6",
+  "D7"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / actor / description
      Previous value: -"Actor code filter (ISO 3166-1 alpha-2; EU for the European Union): US, CN, EU, FR, GB, IN, JP, KR, NL, SA, TW. Named `actor_name` in `get_actors`."New value: +"Actor code filter: a Sovereign Capability Profile register code (ISO 3166-1 alpha-2; EU for the European Union); `get_actors` lists the register. Named `actor_name` in `get_actors`."
  3. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  4. Changed1 schema field changed
    • changedInput schema / properties / include_retired / description
      Previous value: -"Include retired links alongside active ones (default false — active only). Retired links are superseded records kept as frozen snapshots; use this to reconstruct a past state, not to read current membership."New value: +"Include retired links alongside active ones (default false — active only). Retired links are frozen snapshots of links that no longer qualify; use this to reconstruct a past state, not to read current membership."
  5. Changed1 schema field changed
    • addedInput schema / properties / include_retired
      Added value: +{
+  "description": "Include retired links alongside active ones (default false — active only). Retired links are superseded records kept as frozen snapshots; use this to reconstruct a past state, not to read current membership.",
+  "type": "boolean"
+}
  6. Changed1 schema field changed
    • changedInput schema / properties / actor / description
      Previous value: -"Actor code filter: US, CN, EU, FR, GB, IN, JP, KR, NL, SA, TW. Named `actor_name` in `get_actors`."New value: +"Actor code filter (ISO 3166-1 alpha-2; EU for the European Union): US, CN, EU, FR, GB, IN, JP, KR, NL, SA, TW. Named `actor_name` in `get_actors`."
  7. Changed1 schema field changed
    • changedInput schema / properties / actor / description
      Previous value: -"Actor code filter: US, CN, EU, FR, GB, IN, JP, KR, NL, TW"New value: +"Actor code filter: US, CN, EU, FR, GB, IN, JP, KR, NL, SA, TW. Named `actor_name` in `get_actors`."
  8. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the description isn't burdened there. Instead it adds substantive behavior the annotations can't convey: retirement is monotonic ('retired links are never restored', a fresh assessment enters as a new link at the next sequence), tier-dependent field availability, and what the metadata block contains.

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 purpose is front-loaded in the first sentence and the length is largely justified by the lack of an output schema, since the middle passages document the returned fields. It is dense and somewhat exhausting to parse, with long parenthetical chains, but almost every clause carries usable technical information rather than filler.

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 carries the full return-value burden and discharges it thoroughly: link_type values, attribution, entity, identity/lifecycle fields, tier-gated analytics fields, and the metadata block with status_counts and last_updated. Specifying the default active/retired behavior closes the remaining gap for a zero-required-param tool.

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 — concrete actor code examples with the caveat 'GB, not UK' that the ISO alpha-2 schema wording leaves ambiguous, and restates the include_retired semantics in behavioral terms (frozen snapshots).

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 event↔dimension membership links') and immediately scopes it to what events qualify or contribute to for each actor's SCP dimensions. It also explicitly differentiates itself from the sibling it is closest to by naming `get_capability_signatures` for the higher-order derivation work.

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?

Gives explicit filter options (actor, dimension, event_id), states the default behavior (active links only), explains what `include_retired` is for and when NOT to use it ('to reconstruct a past state, not to read current membership'), and routes to the alternative tool for signatures.

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