Drupal Code Query MCP Server

Return one core change record in full: title, flavour, target version, machine-checkable tracks, linked issues, linked core symbols, and contrib adoption counts. To find records, use list_change_records or the change_record_nids from what_changed. For one symbol's detail, use lookup_core_symbol. - flavour: coming-break (an API going away), coming-new-API (an API added), landed-but-still-relevant (shipped), policy-only (no code target, no adoption). - Adoption counts contrib development branches only. legacy: still calls the going-away side. migrated: moved to the new side. - Returns counts across every affected project plus a ranked head, outstanding first. For one project, use project_upgrade_report; do not raise top_projects. - symbols: the core API the record is about. role: from (going away) or to (replacement). Use the fqn with lookup_core_symbol. Empty means the catalog links no symbol; that is common.

List the core change records (the human write-ups) that target a range of core versions, tagged by flavour and ranked, with counts. For the symbol-level diff, use what_changed. For one record in full, use get_change_record. - Bounds are inclusive. Forms: 11.2, 11.2.x, 11.2.0, 11, 11.x. A bare major covers every minor of it. - Flavours: coming-break (an API going away), coming-new-API (an API added), landed-but-still-relevant (already shipped). policy-only records target no version and never appear here. - project: one machine name. Each record then has the count of that project's development branches still on the legacy side. - Returns the count of every record in range plus a ranked head. Each entry has its nid for get_change_record.

Answer "what is this contrib project, how big is it, which core versions does it support, what moves with it" for one drupal.org project. Pending change records: project_upgrade_report. Core symbols it calls: list_symbol_users. - project: title, type, status, security, installs. installs_by_version: install base per contrib version. - dev_branches: each scanned development branch, with installs, core_constraint, core_minors, latest commit date and era. core_constraint: the composer constraint of the newest release on that line, as drupal.org publishes it. The unreleased tip is excluded. core_minors: the minors it admits; a minor counts when any patch satisfies. latest_core_minor: the newest admitted. - releases: newest first, up to releases, each with core_compatibility and security. release_count, supported_branches. missing_sections: what the bundle could not fill. - related (summary): requires and required_by counts with the top 3, co_installed top 3 or a note, delta_12m per release line ("*" is the total). - member_of: how many roots pull this project in (count), and up to 10 {root, depth}, shallowest and alphabetical first. - include=["related"]: related becomes the full report. requires: every dependency, via info_yml or composer, core modules left out. required_by: paged by installs, with count and next_offset; page with dependents and dependents_offset. co_installed: rho, rank, method residual_spearman, or a note. - include=["trend"]: trend has months (oldest first), series per release_line aligned with months (null: no count, "*": total), and lines. Each line: installs_now, share, delta_3m, delta_12m, delta_36m, peak, first_seen, last_seen. Counts are drupal.org month-end installs. - Unknown project: error. An included section refuses when the bundle predates its view.

Answer "is this contrib project ready for a target core version, and what work is left". For one record's detail, use get_change_record. For a symbol's users, use list_symbol_users. - A record applies when it targets the target version or earlier, and a development branch of the project matched one of its tracks. - Verdict per record: outstanding (a branch still calls the going-away side), in_progress (some branches moved), adopted (all moved). - Returns counts by verdict, then a ranked head of outstanding records with file and line evidence from the project's own code. - Each entry has the count of other projects outstanding on the same record, and its nid for get_change_record. - removed_symbols: core symbols removed by the target, or scheduled for removal at or before it, that the project's development branches still reference. Each has occurrences, files, and the replacement when the catalog lists one. They need no change record: a class moved to another module, a service dropped. removed_symbol_count: the whole set. The head is newest removal first, then by occurrences. Test and test-support symbols are left out.

List the contrib classes that extend, implement or use a core class, interface or trait, one row per edge with file and line, paged. Example: "who subclasses FormBase". Call-site counts: list_symbol_users. The symbol's status: lookup_core_symbol. - target: with or without the leading backslash. An unknown target is refused with a pointer at lookup_core_symbol; a fragment there lists candidates. rel_kind: one of extends, implements, uses_trait. project: one machine name. - Development branches only. edge_count: every edge. project_count: projects. count: edges after the per_project cap. project_edges on each row: the project's full count. per_project=50 with project= lists one project in full. - Rows are ordered by project installs, project, source_fqn. Each row: project, branch, installs, source_fqn, rel_kind, file, line, project_edges. limit ≤ 100. next_offset is absent on the last page.

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. - not_indexed: the repos the index lacks. A project with no installs and no recent release is not indexed.

Run read-only DuckDB SELECTs over the dataset behind the other tools, for a question none of them asks. Call describe_dataset first; it lists the 36 views, their columns, joins and recipes. Prefer a typed tool when one fits. - statements=[…]: up to 5 statements in one call, one result or error each. - Result: columns, and rows as arrays, up to max_rows (≤ 500, default 100) and 16 KB. When truncated is true: aggregate, filter, or use LIMIT and OFFSET. One SELECT (or SHOW, DESCRIBE, FROM-first), no semicolon, 15 s limit, nothing outside the bundle. - Dev-branch isolation: JOIN contrib_branch and filter kind = 'dev_branch' AND project <> 'drupal' before counting projects. change_record_adoption, symbol_usage and core_symbol_evidence hold release tags too. core_symbol_evidence is the full rollup; symbol_usage is its string-scan subset. - Adoption polarity: legacy is still on the old API (not adopted); migrated is adopted. Versions are text: compare *_seq integers (major*1000+minor). Never SUM(usage) across branch rows. - Errors list the views, the columns of the views you used, or the join map. An empty result over an fqn without a leading backslash gets a hint. - The same views are downloadable as parquet under https://api.tresbien.tech/data/docs. Its cookbook targets api.duckdb plus prelude views this mirror does not have, so take recipes from describe_dataset.

Learn the dataset before writing SQL for query_dataset. Call it with no arguments first. Returns text. Prefer a typed tool when one answers the question. - No arguments: one line per view, the join map, the four invariants, the causes of empty results, and the recipe index. The invariants: dev-branch isolation, no SUM(usage), *_seq compares, adoption polarity. Empty results come from fqn forms, placeholders and machine name forms. - view=<name>, or views=[…] for several in one call. Returns the columns with types and descriptions, an example filter that returns rows, and the joins into the view. - recipe=<id>: a ready-to-run statement for a common question. Fill in the placeholders and run it with query_dataset. Recipes cover who uses a symbol, deprecated symbols per project, and a change record's adoption. Others cover symbols deprecated between minors, one project's deprecated uses, and change records between minors.

Answer "is this core symbol safe to use, and who still uses it" for one symbol. A name that resolves to nothing returns the catalog entries containing it instead. Every user in pages: list_symbol_users. Changed between versions: what_changed. Code text: search_code. - fqn forms: a namespaced name with or without the leading backslash, a bare function or constant name, a prefixed pseudo-symbol, or a fragment. Pseudo-symbols: fn:check_markup, core:hook:preprocess_page, core:library:claro/drupal.shortcut. Fragments: fromRoute, EntityInterface. - Resolved (found true): symbol, with status flags. removed: gone. scheduled_removal: still present, @deprecated gives the removal version. deprecated, internal. placeholder: a catalog row no scanner located. audience: contrib, test_support, test or theme. usage: contrib development branches only, from the evidence rollup as of evidence_built_at. It has projects and branches counts, plus top_projects (≤ 30) by install base. change_records: records that touched the symbol, each with nid for get_change_record. - Not resolved (found false): count: catalog entries containing the fragment, case-insensitive, public symbols only; kind narrows. candidates: a head of up to candidates entries, each with fqn, kind, subsystem, stamps, projects_using, change_record_nids. Entries starting with the fragment come first, then by projects_using. Call again with one fqn.

Does each composer patch still apply to the release the site installed, and is its fix already in that release? - Send composer_json and composer_lock after composer update. Add patch_files for every patch, a local one read from disk and a URL one fetched by you. Every extra.patches entry is checked at its installed version in one call. - Do not download releases. Do not run patch --dry-run. - Send a package's patches together, in the order composer.json lists them. - items: up to 50 of {project, version, patch, title}, in place of the composer files. project: the drupal.org machine name (webform) or composer name (drupal/webform); drupal or core for Drupal core. version: the installed composer version (1.13.0, 2.0.0-beta4, 11.4.5). patch: the diff text, or its URL on www.drupal.org/files/issues or a git.drupalcode.org merge request or commit, ending .patch or .diff. - Per item. tag: the release tag matched, or unknown_version. applies_at: the -p level at which git apply passes, null when none. fuzzy: true when it applied only with reduced context and whitespace ignored; review it. hunks_failed: [{file, line, reason}]. reverse_applies: true when the patched lines are already in the tag. mr: the merge request state when the patch is an MR URL. merged_in_version. suggested. failure_mode: set when a patch applies and a file it touches no longer parses; keep the patch and fix the file. syntax_errors: the files behind it, one per file, path then the parser's message. - suggested: the verdict. merged: the fix is in the release; drop the patch. applies: keep the patch. conflicts: call reroll_patch with that item. unknown: see error. - next_step: the follow-up calls and the row count the report must have. counts: the verdict tally; check the report's table against it. An item that could not be judged comes back unknown with the reason in error. Report it as unclear. Never leave the row out. - hunks_shipped, files_shipped: the parts of a patch already in the release verbatim. On a conflicts row, check whether the rest is still needed before re-rolling. moved_to: on a failed hunk, the release path of the renamed file. - core_references: what the added code references in core, checked at target_core. flagged: removed or moved classes, and calls whose argument count does not fit the target signature, each with file, line, change_record and replacement. parent::__construct is checked against the constructor of the core parent class. deprecated: a short side list. checked: how many references the catalog knows. Scope: added lines and direct references only (extends, implements, trait use, new, static calls, parent::__construct). A patch that does not apply has a note instead. - Verdicts come from git apply --check against the tag. An applies patch can still be wrong at runtime.

List drupal.org projects after filters, largest install base first, paged. Examples: "top modules without an 11.4 branch", "themes over 10k installs without security coverage". One project: project_profile. Its pending records: project_upgrade_report. - Filters combine: type, min_installs, security (covered, not-covered, revoked), core_minor (+ missing), era (d8plus, pre_d8), member_of (+ max_depth). All apply to count and rows. - core_minor reads the composer constraint of the newest release on each development branch. A minor counts when any patch of it satisfies the constraint. An unreleased tip change is not seen. missing=true keeps projects with no branch declaring it: the upgrade gap list. - member_of keeps one root's members, direct and transitive; max_depth (needs member_of) drops members past that many requires away. A filtered list adds membership: root_release, complete, unread_count and unread (up to 20, package + cause). - Row: machine_name, title, type, installs, security, status, dev_branches (branch, installs, core_minors, era), latest_release, cms_depth, member_of_count. cms_depth is the row's membership depth under the cms root; member_of_count is how many roots include it. A project in no root has neither; a project that is not a cms member has member_of_count alone. count: projects. next_offset is absent on the last page.

Re-roll one composer patch that check_patches reported conflicts or fuzzy: a new diff that applies to the installed release. Call check_patches first for the whole list. Call this once per patch that came back conflicts or fuzzy. - Input: project, version, patch, title, base. patch is the diff text; this service downloads nothing, so fetch a URL patch yourself and send what came back. base is the release the site had before the upgrade. One patch per call. A hand-made patch without index lines is merged from base when it applies there, else from the newest tag it applies to. reroll.base is the tag used. - drop_tests: leave it out and the re-roll drops every file the release package omits. false keeps every hunk, for a site installed from source. reroll.dropped_paths lists what went. - reroll.verified true: the service already ran the check. reroll.verified_by: the command, the -p level and the tag. Write reroll.patch to the patch file and move on. Do not run git apply --check or patch --dry-run. Do not diff against a copy of the release. composer install is the test. - After a conflicts result, send the same project, version and patch again with resolutions, one per region of reroll.conflicts[].hunks. A resolution is {file, region, choice: release|patch}, {file, region, text}, or {file, region, delete: true}. The service re-merges with your decisions and apply-checks the diff. What comes back is the finished patch file: write it and run composer install. Do not read the release files, edit the patch by hand, or dry-run it. - reroll.status clean: every file merged, or GNU patch applied every hunk, and the diff apply-checked against the release, reroll.verified true. Write reroll.patch as the new patch file; no re-test needed. An empty reroll.patch with reroll.note means the release already has the change; suggested is merged. - reroll.status conflicts: reroll.patch holds the hunks that merged cleanly, apply-checked when reroll.verified is true. Each file in reroll.conflicts has hunks with the three sides of every region. release: what the release has. base: what the patch was written against. patch: what the patch wants. release_line and release_context: the release file's numbered lines around the region. Write the missing hunks from those and append them to reroll.patch. No download, file read or dry-run is needed. - reroll.syntax_errors: files that do not parse after the merge, with the parser's line. reroll.verified is false then, though the diff applies. Fix the text of the resolutions on those files and call again. - reroll.status unavailable: no release takes the patch, or it was made from a commit in no release; reroll.error says which. Re-roll by hand from hunks_failed. - reroll.patch paths are relative to the repository root. Contrib patches apply at -p1. Core patches start with core/ and apply at -p2 from web/core. patch_truncated: the diff was cut to the result budget; POST /v1/patch/check on api.tresbien.tech with reroll: true returns it whole. - A patch already in the release (merged), or one git apply accepts unchanged, returns its verdict with reroll null. A patch that applies only because a lenient sweep took it (fuzzy) is re-rolled, since a strict patch manager refuses it. Its re-roll keeps the lines GNU patch writes with fuzz, the code a lenient patch manager installs, and reroll.base stays empty. - core_references: as on check_patches, read from the re-rolled diff when the merge was clean. Removed or moved core classes, and calls whose argument count no longer fits the target signature, at target_core.

Which of a site's drupal/* packages need a new release for a target core, and which have none? Send composer.lock and composer.json once; do not query one package at a time. The answer is the release scan for every package, plus extra.patches as check_patches items. Constraints are read by composer's own semver library. - composer_lock: the whole file, or its path to get the upload command. A real lock does not fit a call. With the path, the files go from disk to the api by curl and only the plan comes back. composer_json: adds constraints and extra.patches. patches_file and patches_lock: the two documents a site on cweagans/composer-patches 2.x keeps its patches in, since such a site declares none under extra.patches. Sent as text with a lock path, the command lists every patch to send. target_core: 11.4, 11.4.5, or latest for the newest core the site's constraint allows. Without patches, target_from holds the package whose constraint decided latest. When the site requires no core package, latest is the installed core and target_from says so. Empty scans against the installed core (target_is_installed): what can be updated without a core upgrade. - installed_unknown: the release data does not have the installed version; the row offers no older release. installed_from_tag: the project's git tag answered instead. Neither is a finding about the site. - A sub-module has no releases of its own; drupal.org packages it as a metapackage built from its project's release. Its row says submodule_of and has that project's answer. The lock's type, require and extra.drupal.datestamp fields pair a metapackage with its project. - rows, problems first. no_release: no published release supports the target; latest_any and dev_branch say what exists. update: a compatible release the site does not have; latest, latest_core. unknown: not a drupal.org project in the bundle; note says where its releases are. current: installed_supports and nothing newer needed; such a row has package, installed and installed_supports only. counts covers every package even when rows are cut. - candidates, on every row that is not current: the newest three releases, each with version, core constraint, date and supports_target. project_profile adds installs and branches to the same three. - patches: one item per declared patch with the installed version filled in. Pass them to check_patches after composer update; local paths need the file text. A patch on a package outside drupal/ gets no item and no row; outside_drupal lists it. - patches:true answers with plan instead: every patch judged against the release its package would install for target_core. plan.counts: the verdict tally. plan.package_counts: the scan tallies. plan.no_release: the packages that block the target. plan.patches: one row per patch needing a decision (conflicts, unknown, merged, and an applies that only a lenient apply took). plan.applying: the number that apply with nothing to decide. The scan rows are not in a plan; call again without patches for them. - A patch whose package has no release for the target is judged against the branch when the lock installs a dev version. Otherwise it is unknown, with the reason in note. plan.warnings: a package is in no_release because of something the site controls. Each warning gives the requirement to change: its own constraint, or its minimum stability. A row's project for reroll_patch is its package without the drupal/ prefix. - A plan never has a re-rolled diff. plan.next_step points at reroll_patch, one call per patch, when any patch needs a re-roll. - bundle_date: when the release data was published. A release after it is invisible here. Confirm a no_release with composer show or drupal.org before acting.

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.

List every contrib project using one core symbol, or any symbol in a class of symbols, one row per project, paged, with the matched symbols. lookup_core_symbol answers one symbol with a head of 30. - Pass fqn, or filters: kind, status (deprecated, scheduled_removal, removed), subsystem, removal_in (13.0), deprecated_in (11.4). Example: "top modules still calling a method going away in 13.0" is kind=method, status=scheduled_removal, removal_in=13.0. Filters take public symbols only. - Development branches only, from the evidence rollup as of evidence_built_at. count: projects. symbol_count: matched symbols. symbols_matched: those symbols, up to matched, most used first, each with stamps, projects_using and change_record_nids. - Rows are ordered by installs, occurrences, name. Each row: project, title, installs, branch, branches, symbol_count, occurrences, symbols. symbols: heaviest first, each with fqn, kind, removal_in, occurrences, files and change_record_nids for get_change_record. next_offset is absent on the last page.

Answer "what changed in the core API between two core versions": symbols added, deprecated and removed, as ranked groups with counts. One symbol: lookup_core_symbol. Human write-ups: list_change_records. Every row of one bucket: flat=true with bucket, paged. Every row of the whole diff: the result's bulk block, with attach and sql for the published catalog. Write those rows to a file, so they stay out of the context window. - Bounds are inclusive. Forms: 11.2, 11.2.x, 11.2.0, 11, 11.x. The same version twice is one minor. Upgrading 11.2 → 11.4 means from=11.3. Buckets are independent. - Grouped (default): a head entry is a symbol group; grouped_by is change_record, name_prefix or singleton. head: groups, up to 5. count: symbols. group_count: groups. members: up to 3 per group, highest usage first. Group fields appear only when every member agrees. Rank: max_projects_using desc, then member_count magnitude, tier, count, key; ranked_by states it. When head_covers_all_callers is false, narrow with kind or min_projects_using, or page with offset. - Flat (flat=true, bucket=added, deprecated, removed): rows by projects_using then fqn. Each row: fqn, kind, subsystem, stamp, projects_using, removal_in, removal_kind, replacement when the catalog lists one, change_record_nids. count: public symbols in the bucket after filters. limit ≤ 100. next_offset is absent on the last page. - Filters apply to every count. internal_excluded and test_theme_excluded are counted apart and left out. unplaceable_symbols have no minor in their stamp. - Usage: contrib development branches only, from the evidence rollup as of usage_evidence_built_at. 0 means no caller observed. - change_record_nids: for get_change_record. removal_kind observed: gone. removal_kind scheduled: promised and still present; say "scheduled for removal in 13.0".

Answer "does this WordPress block theme convert to Drupal with WordPal". The WordPal gallery converts every block theme on wordpress.org each night. With slug: one theme and its routes. Without slug: counts by status and the most installed themes. - version: the theme version wordpress.org lists now. run: the run the gallery shows. run.theme_version is the version it converted, which can be older. - run.status (exact, diff, failed) is a verdict on the home page only. exact: its markup has no difference and its screenshot matches the WordPress screenshot. diff: the markup differs, the screenshots differ, or the two pages could not be compared. failed: no pair of home page screenshots, as when the conversion fails. - Filters combine: status (run.status), tag, q. count: themes that pass all three. by_status: themes that pass tag and q, per status. - Row: slug, name, installs, version, and run with status, routes_measured, routes_matching, markup_diffs_total. Up to eight pages are compared per theme. markup_diffs_total sums their markup differences. - theme: the row, plus author, tags and page_url. Its run adds plugins to install first, convert_command, reason when failed, wordpal_release and image links. - run.routes: route, markup_outcome (match, diff, skipped, error) and markup_diffs. A markup difference is an element, a class, an attribute or an inline style that differs. - A route whose screenshots were compared also has visual_outcome (match, diff, unstable, error), visual_bands, visual_changed, wp_height and drupal_height. - wp_only_rows and drupal_only_rows: pixel rows that one screenshot alone has. visual_bands and visual_changed count the rows both screenshots have. - history: every run the gallery has shown for the theme, newest first, home page only. direction (improved, regressed, same, changed) compares a run with the run before. - next_offset is absent on the last page.