Skip to main content
Glama

Navigation depth

nav_depth_check
Read-only

Analyze a navigation tree. Give tree as indented text (2 or 4 spaces or tabs, bullets optional, or 'A > B > C' paths) or JSON (nested {label, children} objects, arrays or a key-value map). Optionally maxDepth (default 4), maxBreadth (default 9) and pages (pages or labels that should be reachable, to find orphans). Returns node and leaf counts, depth, nodes and average children per level, the widest branch, items deeper than the limit, branches wider than the limit, one-child branches, naming collisions (siblings with the same name, the same name in different branches, a child repeating its parent), and orphans. Structural checks only; limits are conventions and there is no magic number.

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": {
      "tree": "<tree>"
    },
    "name": "nav_depth_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
treeYesIndented text, 'A > B' paths, or JSON
pagesNoPages or labels that should appear in the tree
maxDepthNoDeepest acceptable level, default 4
maxBreadthNoMost items per level, default 9

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description's added value is the caveat "Structural checks only; limits are conventions and there is no magic number" — a genuinely useful signal that exceeding a limit is advisory, not an error. It also enumerates the full return surface, which compensates for the missing output schema.

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?

Front-loaded with the action, then input formats, then parameters, then the return list — a sensible order with essentially no filler. Slightly dense as a single paragraph, but every clause carries information.

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?

There is no output schema, and the description fully compensates by enumerating what is returned (node/leaf counts, depth, per-level nodes and average children, widest branch, over-limit items, one-child branches, collision types, orphans). Combined with the input-format guidance and the advisory caveat, an agent has everything needed to call and interpret it.

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 goes further: it spells out the accepted tree encodings (indentation widths, bullet optionality, 'A > B > C' paths, nested JSON/array/map), restates the defaults (maxDepth 4, maxBreadth 9), and clarifies that `pages` is used to detect orphans — meaning not obvious from the schema's "Pages or labels that should appear in the tree".

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 ("Analyze a navigation tree") and enumerates the exact structural findings returned (depth, breadth, one-child branches, naming collisions, orphans). It is clear what the tool does, though it never names a sibling (e.g. tree_test_scorer, sitemap_to_outline) to disambiguate among the many tree/hierarchy tools.

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?

Usage is implied through the accepted input formats and the optional `pages` flag framed as "to find orphans", so an agent can infer when the tool applies. However there is no explicit when-to-use/when-not guidance and no routing to alternative sibling tools.

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