Skip to main content
Glama

Drupal Code Query

by tech.tresbien

Search contrib and core code

search_code
Read-onlyIdempotent

Search the source of every indexed contrib project, plus core, for a code pattern: which files, or with by_repo which projects. Who-uses-a-core-symbol counts: list_symbol_users or lookup_core_symbol.

  • query is a regex. Set literal for exact text with ( [ ] . $ : or a space, and put r: f: lang: case: sym: b: terms in filters. repos: project machine name list. The index runs RE2, which has no lookaround or backreferences.

  • .module, .install, .theme, .engine, .profile and .inc count as PHP: lang:php includes them and sym: resolves inside them. No language filter is applied for you.

  • Returns total_matches and total_files plus a head of files (repo, path, matching lines), limit ≤ 50. by_repo: (repo, file_count) rows from a pull of up to 1000 files; total_files is the ceiling; truncated when cut. A parse error returns the index's own message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoFiles to return, default 20, cap 50. Ignored with by_repo.
queryYesCode to find, a regex unless literal is true. Filters may be inline when literal is false, else in filters. Example: hook_form_alter f:\.module$
reposNoRestrict to these projects, by machine name, in one query.
by_repoNoReturn repos as (repo, file_count) instead of files. Pulls up to 1000 files; total_files is the ceiling.
filtersNoZoekt filters appended as written: r:<repo regex> f:<path regex> lang:<language> b:<branch> sym:<symbol> case:yes.
literalNotrue: query is matched as exact text. Use it for text with ( [ ] $ . such as #[Hook(. With literal, filters go in filters.

Schema Changelog

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

  1. Changed1 schema field changed
    • changedInput schema / properties / literal / description
      Previous value: -"true: query is exact text, not a regex. Use it for text with ( [ ] $ . such as #[Hook(. With literal, filters go in filters."New value: +"true: query is matched as exact text. Use it for text with ( [ ] $ . such as #[Hook(. With literal, filters go in filters."
  2. Changed5 schema fields changed
    • changedInput schema / properties / by_repo / description
      Previous value: -"Return repos as (repo, file_count) instead of files; pulls up to 1000 files, total_files is the ceiling."New value: +"Return repos as (repo, file_count) instead of files. Pulls up to 1000 files; total_files is the ceiling."
    • changedInput schema / properties / limit / description
      Previous value: -"Files to return, default 20, cap 50; ignored with by_repo."New value: +"Files to return, default 20, cap 50. Ignored with by_repo."
    • changedInput schema / properties / literal / description
      Previous value: -"true = query is exact text, not a regex: use it for text with ( [ ] $ . such as #[Hook( ; with literal, filters go in filters."New value: +"true: query is exact text, not a regex. Use it for text with ( [ ] $ . such as #[Hook(. With literal, filters go in filters."
    • changedInput schema / properties / query / description
      Previous value: -"Code to find; a regex unless literal is true. Filters may be inline when literal is false, else in filters. Example: hook_form_alter f:\\.module$"New value: +"Code to find, a regex unless literal is true. Filters may be inline when literal is false, else in filters. Example: hook_form_alter f:\\.module$"
    • changedInput schema / properties / repos / description
      Previous value: -"Restrict to these project machine names (one query)."New value: +"Restrict to these projects, by machine name, in one query."
  3. Changed1 schema field changed
    • changedInput schema / properties / literal / description
      Previous value: -"Treat query as exact text (for ( [ ] $ . as in #[Hook(); filters go in filters."New value: +"true = query is exact text, not a regex: use it for text with ( [ ] $ . such as #[Hook( ; with literal, filters go in filters."
  4. Added

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare read-only and idempotent behavior, and the description adds substantial behavioral detail: RE2 regex limitations, .module/.install/.inc counted as PHP, no automatic language filter, result shape with total_matches/total_files, by_repo semantics, limit cap, and parse-error propagation.

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 every sentence earns its place. It opens with the core purpose, then covers regex syntax, language handling, and return behavior in a structured way. No filler or redundant restatement of the tool name is present.

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 no output schema, the description properly explains return values: total_matches, total_files, head of files, and by_repo rows. It also covers edge behavior like truncation, the 50-result cap, the 1000-file pull, and parse-error messages, making it sufficiently complete for correct invocation.

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 goes beyond the schema by explaining RE2's lack of lookaround/backreferences, which file extensions count as PHP for lang:/sym:, how literal mode interacts with filters, and the by_repo pull/truncation behavior. This adds real meaning to query, literal, filters, and by_repo.

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 verb and resource: 'Search the source of every indexed contrib project, plus core, for a code pattern.' It also distinguishes the tool from siblings by explicitly saying symbol-use counts belong to list_symbol_users or lookup_core_symbol.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit routing: use list_symbol_users or lookup_core_symbol for 'Who-uses-a-core-symbol counts.' It also provides practical guidance on query construction, filters, literal mode, and the absence of an applied language filter, helping the agent decide how to invoke the tool.

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 toolsInspect
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