Skip to main content
Glama

Traverse connections graph

traverse_graph
Read-only

Multi-hop graph walk from a start node, with filters. This is the EXACT-enumeration tool: 'every recipe using brown sugar' (start='ingredient:brown-sugar', node_types=['entry']), 'all of Grandma's recipes' (start='author:...', node_types=['entry']), 'the ingredient fingerprint of mom's collection' (start='user:...', depth 2, node_types=['ingredient']). Results are complete up to limit — if truncated, the response says so. Node ids are ':' — e.g. 'entry:' (prefix a search_recipes hit id with 'entry:'), 'ingredient:brown-sugar', 'author:mother-in-law', 'appliance:oven', 'user:'. User-supplied metadata is traversable too: 'tag:' (a shared free-form label) and 'property::' (a shared key=value, e.g. 'property:region:alaska') — every entry carrying that tag/value links to the same node. Recipes with named sub-preparations carry 'component::' nodes (HAS_COMPONENT from the entry; the component links to its own ingredients/steps) — e.g. "what else uses this sauce?" is one hop.

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": {
      "start": "<start>"
    },
    "name": "traverse_graph"
  }
}

Input Schema

NameRequiredDescriptionDefault
depthNoMax hops from start (default 1).
limitNoMax nodes visited (default 100).
startYesStart node id (bare recipe ids auto-resolve).
edge_typesNoOnly follow these relationship types.
node_typesNoOnly RETURN nodes of these types (traversal still passes through others).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the transparency burden. It adds exact-enumeration semantics, truncation signaling, node-id conventions, and metadata traversal behavior—far more than the annotations require.

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

Conciseness5/5

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

The description is dense but each segment contributes: core operation, exactness/truncation, ID format, metadata nodes, and component-node nuance. The core definition is front-loaded and the examples compress a lot of usage into a small space.

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 should cover result semantics; it states completeness and truncation behavior and gives node-id conventions that help parse results. It does not specify the result shape or fields beyond that, which is a small gap for a complex graph traversal 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 description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the '<type>:<key>' node-id format with real examples, clarifying what node_types controls, and showing valid start strings for depth and node_types usage.

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 first sentence names a specific operation—multi-hop graph walk from a start node with filters—and immediately distinguishes it with 'EXACT-enumeration tool' and concrete examples. This clearly separates it from graph siblings like find_graph_connection, get_graph_node, and get_graph_overview.

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 clear when-to-use context through examples and explicitly frames the tool as exhaustive enumeration. It does not name alternatives or list when not to use it, so it falls short of a full 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources