PerspectiveGraph

Overview Schema Source Related Servers Discussions Admin

routes_to_target

Read-onlyIdempotent

Enumerate the k best distinct routes to a sensitive asset. Reveals whether entry paths share a choke point, showing which single hop removal cuts all access.

Instructions

Enumerate the k best distinct routes that reach a named sensitive asset. Answers 'how many ways in are there, and do they share a choke point' - which single-path views hide. Cutting a hop that every route traverses removes them all; cutting one that appears in a single route removes one. Each route comes with its hops, ready to hand to simulate_fix. It returns the best k and has no further page.

Input Schema

Name	Required	Description
`k`	No	How many distinct routes to return, best first. Fewer routes come back when fewer exist.
`from`	No	Optional entry point to start from, by name or node id. Omit to consider every internet-exposed entry point.
`target`	Yes	The sensitive asset to reach, by name or node id: a `name` under get_posture's crownJewels (e.g. 'account-admin (effective)'), or an `id` from search_assets. A target nothing reaches returns an empty list, not an error.

Output Schema

Name	Required	Description	Default
`kShortestPaths`	No	The distinct routes to the target, most likely first. Empty when nothing reaches it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.38.1Oct 14, 2026

changedInput schema / properties / from / description

Previous value: -"Optional entry-point name to start from."New value: +"Optional entry point to start from, by name or node id. Omit to consider every internet-exposed entry point."

changedInput schema / properties / target / description

Previous value: -"Sensitive asset name, e.g. 'account-admin (effective)'."New value: +"The sensitive asset to reach, by name or node id: a `name` under get_posture's crownJewels (e.g. 'account-admin (effective)'), or an `id` from search_assets. A target nothing reaches returns an empty list, not an error."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "kShortestPaths": {
+      "description": "The distinct routes to the target, most likely first. Empty when nothing reaches it.",
+      "items": {
+        "properties": {
+          "id": {
+            "description": "Id of the route. explain_attack_path takes it only when list_attack_paths returns the same route; an alternate that exists only here is described by its steps below.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "nodes": {
+            "description": "The assets the route passes through, entry point first, target last. A node that appears in every route is a choke point.",
+            "items": {
+              "properties": {
+                "label": {
+                  "description": "Asset type, e.g. LoadBalancer, Container, IAM_Role, Bucket, CVE.",
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "name": {
+                  "description": "Asset name.",
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                }
+              },
+              "type": [
+                "object",
+                "null"
+              ]
+            },
+            "type": [
+              "array",
+              "null"
+            ]
+          },
+          "score": {
+            "description": "End-to-end probability that an attacker completes the route, 0-1. A modelled estimate, not a measured rate: see get_score_trust.",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "steps": {
+            "description": "The hops, in order.",
+            "items": {
+              "properties": {
+                "edgeType": {
+                  "description": "The relationship, e.g. EXPOSES, ASSUMES, HAS_PERMISSION, CAN_ESCALATE_TO.",
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "from": {
+                  "description": "Node id the hop starts at. Usable as `from` in a simulate_fix cut.",
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "probability": {
+                  "description": "Probability an attacker crosses this hop, 0-1.",
+                  "type": [
+                    "number",
+                    "null"
+                  ]
+                },
+                "to": {
+                  "description": "Node id the hop ends at. Usable as `to` in a simulate_fix cut.",
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "weightBasis": {
+                  "description": "Where that probability came from: kev, epss or runtime are observed evidence; cvss, severity or heuristic are estimates.",
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                }
+              },
+              "type": [
+                "object",
+                "null"
+              ]
+            },
+            "type": [
+              "array",
+              "null"
+            ]
+          }
+        },
+        "type": [
+          "object",
+          "null"
+        ]
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedSep 15, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuine behavioral value beyond that: the 'no further page' note (no pagination), the hop-level payload that feeds simulate_fix, and the choke-point semantics of cutting shared vs unique hops.

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?

Purpose is front-loaded in the first sentence, and the remaining sentences each carry real content (choke-point reasoning, handoff to simulate_fix, no pagination). Slightly verbose but no filler that could be cut without losing behavior.

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 an output schema present, the description need not detail return values, and it covers the remaining key behaviors: pagination absence, empty-list-not-error (in the target param), and the downstream simulate_fix handoff. An agent has what it needs to call it correctly.

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 coverage is 100%, so all three parameters are fully documented in the schema, establishing the baseline of 3. The description only echoes the 'k best' concept and does not add syntax or format meaning beyond what the schema already provides.

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?

The description opens with a specific verb and resource: 'Enumerate the k best distinct routes that reach a named sensitive asset.' It contrasts itself against 'single-path views,' giving functional differentiation from the attack-path siblings, though it does not name them explicitly.

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?

It gives clear context for use ('how many ways in are there, and do they share a choke point'), which implies selection over single-path tools, and routes the user forward to simulate_fix. It stops short of an explicit when-not-to-use or a named alternative.

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

Deploy Server