Très Bien Blog: Drupal code query MCP Server

https://mcp.tresbien.tech/mcp
A few months ago I put an api online to search and query the whole Drupal code ecosystem. With the release of some more capable local AI models I thought it could be good to release a MCP server with that same data optimized for LLM use. Same data, different packaging. The address for the MCP server is:
Add the server to your setup of choice and you’ll be able to ask things like: 

  • What changed in core between 11.2 and 11.4 that affects modules like mine (hooks, services, libraries)?”
  • I’m about to change the Field API, which other subsystems’ tests tend to break, and which contrib modules will feel it first?
  • Which contrib projects gained the most installs over the last 12 months, floor 5k?
  • Which projects above 50k installs are shrinking fastest, and who still depends on them?
  • Find clusters of projects that ship together on sites without any declared dependency between them.
  • Profile metatag: versions, core support, and its ecosystem neighborhood.
  • Show me contrib code that already migrated from hook_entity_presave to the #[Hook] attribute.
  • Which core symbols have the most change records attached?
  • Is webform ready for Drupal 12? Show outstanding change records with file and line.
  • Modules over 10k installs not covered by the security team compatible with D11

If you add the MCP server to opencode and ask Qwen3.8: Which core @internal classes are contrib projects extending anyway?, you’ll get something like: 

An example

All the data to answer the questions above is accessible since February at https://api.tresbien.tech, and with the query interface at https://api.tresbien.tech/data/ but something tells me people don’t want to learn the DB schema and write SQL to get to the answer.
I spent quite a bit of time making sure it work with less capable models that can run locally, It’s been significantly more fun playing with this than writing SQL queries.

What’s in there? 

  • search_contrib_code: Search the source of every indexed contrib project, plus core, for a code pattern: which files, or with by_repo which projects
  • get_change_record: Return one core change record in full: title, flavour, target version, machine-checkable tracks, linked issues, linked core symbols, and contrib adoption counts
  • what_changed: Answer “what changed in the core API between two core versions”: symbols added, deprecated, removed, as ranked groups with counts
  • list_change_records: List the core change records (the human write-ups) targeting a range of core versions, tagged by flavour and ranked, with counts
  • lookup_core_symbol: Answer “is this core symbol safe to use, and who still uses it” for one symbol
  • find_core_symbol: Find core symbols by part of their name when the exact fqn is unknown; then call lookup_core_symbol or list_symbol_users with the fqn
  • project_upgrade_report: Answer “is this contrib project ready for a target core version, and what work is left”
  • project_profile: Answer “what is this contrib project, how big is it, which core versions does it support” for one drupal.org project
  • list_projects: List drupal.org projects after filters, largest install base first, paged: “top modules without an 11.4 branch”, “themes over 10k installs without security coverage”
  • project_trend: Answer “how is this project’s install base moving, and on which release line” for one drupal.org project
  • related_projects: Answer “what moves with this project: what it requires, who requires it, what sites install alongside it” for one drupal.org project
  • subsystem_coupling: Answer “what else tends to fail when a merge request touches this core subsystem” from CI history over ~9,000 core MRs; with issue_nid, “which subsystems does this issue touch and what co-fails with them”
  • list_class_relations: List the contrib classes that extend, implement or use a core class, interface or trait, one row per edge with file and line, paged: “who subclasses FormBase”
  • list_changed_symbols: List one bucket (added, deprecated, removed) of the core API diff between two versions as flat rows, paged
  • list_symbol_users: List every contrib project using one core symbol or any symbol in a class of symbols, one row per project, paged, and the matched symbols themselves
  • describe_dataset: Learn the dataset before writing SQL for query_dataset; call with no arguments first
  • query_dataset: Run read-only DuckDB SELECTs over the dataset behind the other tools, for a question none of them asks

174 of the 863 core @internal classes are extended by contrib
dev branches: 205 projects, 468 extender classes. Most-extended:

Drupallayout_builderFormConfigureSectionForm: 12
Drupalmedia_libraryPluginFieldFieldWidgetMediaLibraryWidget:11
DrupalmediaPluginFieldFieldFormatterOEmbedFormatter: 8
Drupalmenu_uiMenuForm: 8
DrupaljsonapiControllerEntityResource: 8
DrupalserializationEncoderJsonEncoder: 8
DrupaltaxonomyTermForm: 7
DrupaluserFormUserPermissionsForm: 9
DrupaluserRegisterForm: 7
DrupalCoreThemeRegistry: 7

Then, you’re free to ask all the details you want. Want the list of modules or classes that extends TermForm? ask. The list of modules that uses the most @internal code from core? spoiler it’s Test Helpers by far. 

Similar Posts