Drupal Code Query

Subsystem co-failure graph

subsystem_coupling

Read-onlyIdempotent

Answer "what else tends to fail when a merge request touches this core subsystem" from CI history over about 9,000 core merge requests. With issue_nid: "which subsystems does this issue touch, and what co-fails with them". No arguments: the list of subsystems, the same one core_symbol.subsystem and list_symbol_users subsystem= use.

subsystem: a name (Views, case-insensitive) or a bucket (module:views, core_lib:Entity). An unknown one is refused, with the nearest matches.
Edge: touched_bucket → failing_bucket (+ subsystem), lift, co_fail_count, touched_count, failed_count, total_mrs. lift = P(fail | touched) − P(fail | any MR). Self edges are left out.
Floors min_lift (0.05) and min_co_fail (3) drop noise. count: edges above them. edges: up to limit (≤ 50), by lift. When nothing clears the floors, the strongest edges are listed with a note.
issue_nid: touched_subsystems first. A note explains an issue with no MR file data.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Edges to return, 1 to 50 (default 20). count says how many pass the floors.
`min_lift`	No	Keep edges with lift at or above this (default 0.05).
`issue_nid`	No	A drupal.org core issue nid: reports the subsystems its merge request touches, then the coupling edges from each.
`subsystem`	No	A core subsystem (Views, Entity API) or a path bucket (module:views, core_lib:Entity). Leave both subsystem and issue_nid empty to get the list of subsystems.
`min_co_fail`	No	Keep edges seen in at least this many merge requests (default 3).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedSep 2, 2026

changedInput schema / properties / min_lift / description

Previous value: -"Keep edges with lift at or above this (default 0.05, the survey report's floor)."New value: +"Keep edges with lift at or above this (default 0.05)."

changedInput schema / properties / subsystem / description

Previous value: -"A core subsystem name (Views, Entity API) or a path bucket (module:views, core_lib:Entity). Leave both subsystem and issue_nid empty to get the directory of subsystem names."New value: +"A core subsystem (Views, Entity API) or a path bucket (module:views, core_lib:Entity). Leave both subsystem and issue_nid empty to get the list of subsystems."

Changed1 schema field changedAug 19, 2026

changedOutput schema / (root)

Previous value: -{
-  "additionalProperties": false,
-  "properties": {
-    "count": {
-      "type": "integer"
-    },
-    "edges": {
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "co_fail_count": {
-            "type": "integer"
-          },
-          "failed_count": {
-            "type": "integer"
-          },
-          "failing_bucket": {
-            "type": "string"
-          },
-          "failing_subsystem": {
-            "type": "string"
-          },
-          "lift": {
-            "type": "number"
-          },
-          "total_mrs": {
-            "type": "integer"
-          },
-          "touched_bucket": {
-            "type": "string"
-          },
-          "touched_count": {
-            "type": "integer"
-          }
-        },
-        "required": [
-          "touched_bucket",
-          "failing_bucket",
-          "lift",
-          "co_fail_count",
-          "touched_count",
-          "failed_count",
-          "total_mrs"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "null",
-        "array"
-      ]
-    },
-    "lift_means": {
-      "type": "string"
-    },
-    "note": {
-      "type": "string"
-    },
-    "ranked_by": {
-      "type": "string"
-    },
-    "subsystems": {
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "bucket": {
-            "type": "string"
-          },
-          "subsystem": {
-            "type": "string"
-          }
-        },
-        "required": [
-          "bucket"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "null",
-        "array"
-      ]
-    },
-    "subsystems_directory": {
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "buckets": {
-            "type": "integer"
-          },
-          "coupling_edges": {
-            "type": "integer"
-          },
-          "issues_touched": {
-            "type": "integer"
-          },
-          "subsystem": {
-            "type": "string"
-          },
-          "symbols": {
-            "type": "integer"
-          }
-        },
-        "required": [
-          "subsystem",
-          "buckets",
-          "symbols",
-          "coupling_edges",
-          "issues_touched"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "null",
-        "array"
-      ]
-    },
-    "touched_subsystems": {
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "files_touched": {
-            "type": "integer"
-          },
-          "subsystem": {
-            "type": "string"
-          }
-        },
-        "required": [
-          "subsystem",
-          "files_touched"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "null",
-        "array"
-      ]
-    }
-  },
-  "required": [
-    "subsystems",
-    "count",
-    "edges",
-    "ranked_by",
-    "lift_means"
-  ],
-  "type": "object"
-}New value: +null

Changed2 schema fields changedAug 19, 2026

changedInput schema / properties / subsystem / description

Previous value: -"A core subsystem name (Views, Entity API) or a path bucket (module:views, core_lib:Entity). One of subsystem or issue_nid."New value: +"A core subsystem name (Views, Entity API) or a path bucket (module:views, core_lib:Entity). Leave both subsystem and issue_nid empty to get the directory of subsystem names."

addedOutput schema / properties / subsystems_directory

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "buckets": {
+        "type": "integer"
+      },
+      "coupling_edges": {
+        "type": "integer"
+      },
+      "issues_touched": {
+        "type": "integer"
+      },
+      "subsystem": {
+        "type": "string"
+      },
+      "symbols": {
+        "type": "integer"
+      }
+    },
+    "required": [
+      "subsystem",
+      "buckets",
+      "symbols",
+      "coupling_edges",
+      "issues_touched"
+    ],
+    "type": "object"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}

AddedAug 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the read-only annotations, the description reveals important behavior: unknown subsystems are refused with nearest matches, self-edges are omitted, lift is defined, floors filter noise, and edge cases like no clearing edges or no MR file data produce notes. This gives the agent strong expectations of output and failure behavior.

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 well-structured with clear bullets. Every line adds operational detail, from accepted inputs to output fields and edge-case notes. Despite its length, there is no filler or redundancy.

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?

With a complex 5-parameter tool and no output schema, the description still explains all modes, parameter forms, output edge fields, defaults, filtering behavior, and special-case notes. Nothing critical is left to guesswork.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds substantial meaning: subsystem names can be case-insensitive names or buckets like module:views, edge fields are enumerated with a precise lift formula, and the interaction of min_lift/min_co_fail with count and edges is explained. This goes well beyond the schema descriptions.

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 description states a specific analytical question ('what else tends to fail when a merge request touches this core subsystem') and names the data source (CI history over about 9,000 core merge requests). It also distinguishes the two main calling modes (subsystem vs issue_nid), so the tool's purpose is unmistakable.

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 usage modes: pass subsystem, pass issue_nid, or pass nothing to list subsystems. It also explains how an unknown subsystem is handled. It does not explicitly contrast this tool with sibling alternatives, but the specialized context makes the intended use clear.

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

All Drupal Code Query tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation4/5

Tools cluster into related families (change records, symbol usage, patch checks), but descriptions and cross-references clearly separate list vs detail vs diff operations. Some adjacent tools like lookup_core_symbol and list_symbol_users require careful reading, yet their purposes are distinct enough for an agent to select correctly.

Naming Consistency4/5

Most tools follow a clear snake_case verb_noun pattern: list_*, get_*, lookup_*, query_, scan_, search_, reroll_, describe_. A few names like project_profile, subsystem_coupling, and what_changed deviate from verb_noun but remain consistent in style and readable.

Tool Count4/5

At 16 tools, the set is slightly above the typical well-scoped range, but the domain is broad: patch lifecycle, composer scanning, symbol lookup, change records, project profiles, dataset queries, and code search. Each tool covers a distinct query surface, so none feels redundant.

Completeness5/5

The toolkit covers the full read-only analysis lifecycle: scanning composer constraints, checking and re-rolling patches, exploring datasets, looking up core symbols and their users, listing change records, profiling projects, and assessing upgrade readiness. No obvious dead ends or missing operations for its stated purpose.

Resources

Need Help?