Skip to main content
Glama
mcp-hyperspace-memory

mcp-hyperspace-memory

Official
by YARlabs

memory_explore_hierarchy

Navigate a memory concept hierarchy to find broader parent concepts or descendant subsumption trees, returning structured JSON for relationship exploration.

Instructions

Explore conceptual hierarchy in memory using Lorentz Cone Subsumption. 'up' navigates to parent/hypernym concepts; 'down' returns the subsumption tree of descendant concepts. Returns a JSON structure of the hierarchy.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "concept_id": "<concept_id>",
      "direction": "<direction>"
    },
    "name": "memory_explore_hierarchy"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax results (default: 32).
directionYes'up' → broader parent concepts. 'down' → specific descendant concepts.
concept_idYesThe memory/concept ID to start from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.2.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full burden. It discloses the return medium ('a JSON structure of the hierarchy') and names the underlying mechanism (Lorentz Cone Subsumption), but says nothing about traversal depth, cost, truncation under the limit, or whether the operation is purely read-only and side-effect free.

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?

Three short sentences, front-loaded with purpose before the direction explanation. The direction sentence largely duplicates the enum descriptions in the schema, which keeps it from a 5, and 'Lorentz Cone Subsumption' is unexplained jargon for most agents.

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

Completeness3/5

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

There is no output schema, so the description must characterize the return value, and 'a JSON structure of the hierarchy' is too thin to tell an agent what shape to expect at varying depths or whether the limit truncates the tree. Direction semantics are covered, but return-shape and scale behavior are not.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description does add the term 'hypernym' alongside parent and frames 'down' as returning a subsumption tree rather than a flat list, which is modest extra meaning, but limit and concept_id are left entirely to the schema.

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

Purpose4/5

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

States a specific verb and resource: 'Explore conceptual hierarchy in memory', with the direction semantics spelled out (up = parent/hypernym, down = descendant subsumption tree). This clearly separates it from flat-retrieval siblings like memory_recall or memory_query_planner, though it never names those siblings explicitly.

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

Usage Guidelines3/5

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

The two-direction semantics imply when each mode applies, but there is no statement of when to prefer this traversal over memory_recall or hyperspace_query_planner, and no prerequisite or exclusion guidance. Usage is reasonably inferable rather than stated.

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