Skip to main content
Glama
duckAsteroid

brindley

by duckAsteroid
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

graph

Read-only

Visualize dependencies as adjacency lists and Mermaid diagrams for a collection's active work, an initiative's neighborhood, or a tag across collections.

Instructions

Dependency graph as an adjacency list plus Mermaid: a collection's active work, one initiative's neighbourhood, or a tag (theme) across collections.

Input Schema

NameRequiredDescriptionDefault
refNoInitiative (ticket/issue): "collection#n" (e.g. "lgm#22"), a bare number, or a path.
tagNo
showNoStatuses to include as nodes beyond active work, e.g. ["done"].
arrowsNofrom: edges point at what an initiative needs (X depends on Y → X --> Y); to: the reverse.
themesNoShow themes: "box", "icon", "label" (or true), or a list such as ["box", "icon"].
relatedNoDraw ## Related links as dotted edges.
externalNofalse leaves out external dependencies and other collections' initiatives.
directionNoWhere the do-first work goes: left-to-right, right-to-left, top-to-bottom, bottom-to-top.
collectionNo
milestonesNoMark each node with the icons of the milestones it counts towards.
include_doneNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.7.0
    • addedInput schema / properties / milestones
      Added value: +{
+  "description": "Mark each node with the icons of the milestones it counts towards.",
+  "type": "boolean"
+}
  2. Changed7 schema fields changedv2.6.0
    • addedInput schema / properties / arrows
      Added value: +{
+  "description": "from: edges point at what an initiative needs (X depends on Y → X --> Y); to: the reverse.",
+  "enum": [
+    "from",
+    "to"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / direction
      Added value: +{
+  "description": "Where the do-first work goes: left-to-right, right-to-left, top-to-bottom, bottom-to-top.",
+  "type": "string"
+}
    • addedInput schema / properties / external
      Added value: +{
+  "description": "false leaves out external dependencies and other collections' initiatives.",
+  "type": "boolean"
+}
    • changedInput schema / properties / ref / description
      Previous value: -"Initiative: \"collection#n\", a bare number, or a path."New value: +"Initiative (ticket/issue): \"collection#n\" (e.g. \"lgm#22\"), a bare number, or a path."
    • addedInput schema / properties / related
      Added value: +{
+  "description": "Draw ## Related links as dotted edges.",
+  "type": "boolean"
+}
    • addedInput schema / properties / show
      Added value: +{
+  "description": "Statuses to include as nodes beyond active work, e.g. [\"done\"].",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / themes
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  ],
+  "description": "Show themes: \"box\", \"icon\", \"label\" (or true), or a list such as [\"box\", \"icon\"]."
+}
  3. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

readOnlyHint=true already declares the safety profile, so the bar is lower. The description adds genuine context by disclosing the return shape (adjacency list plus Mermaid), which the annotations do not. It stops there – no mention of how 'active work' is determined, graph size limits, or cost of the richer modes.

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?

A single dense sentence with the resource and output forms front-loaded, followed by the scope options. Nearly every clause earns its place, though the '(theme)' interjection is slightly redundant against the schema's tag field.

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?

For an 11-parameter read-only tool with no output schema, the description adequately covers what the tool produces and its three entry modes, and the schema documents the individual flags. It is a bit thin on defaults and on how the adjacency-list/Mermaid output is structured in the response.

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 73%, so the schema carries most of the load. The description loosely maps ref to 'one initiative's neighbourhood' and tag to 'a tag (theme) across collections', but adds no meaning for the many boolean flags (external, related, milestones, include_done) or the arrows/direction semantics.

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 resource (dependency graph) and output forms (adjacency list plus Mermaid), plus three distinct scoping modes. It distinguishes itself from generic siblings like list/get but never names an alternative 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 three clauses ('a collection's active work', 'one initiative's neighbourhood', 'a tag across collections') imply which inputs map to which scope, giving some usage context. But there is no when-to-use vs alternatives guidance or any exclusion relative to siblings like list, tags, or get.

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

Deploy Server

Other Tools