"Drupal" matching MCP tools:

• what_changedA

  Drupal Code QueryA

  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".

  ConnectorNo auth

• query_datasetA

  Drupal Code QueryA

  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 29 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.

  ConnectorNo auth

• list_class_relationsA

  Drupal Code QueryA

  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.

  ConnectorNo auth

• search_codeA

  Drupal Code QueryA

  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.

  ConnectorNo auth

• check_patchesA

  Drupal Code QueryA

  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.

  ConnectorNo auth

• list_change_recordsA

  Drupal Code QueryA

  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.

  ConnectorNo auth

• lookup_core_symbolA

  Drupal Code QueryA

  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.

  ConnectorNo auth

• describe_datasetA

  Drupal Code QueryA

  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.

  ConnectorNo auth

• subsystem_couplingA

  Drupal Code QueryA

  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.

  ConnectorNo auth

• reroll_patchA

  Drupal Code QueryA

  Re-roll one composer patch that check_patches reported conflicts: a 3-way merge of the patch onto the installed release, returned as a new diff. Call check_patches first for the whole list. Call this once per patch that came back conflicts. - 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. - 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 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 that still applies (applies_at set) or is already in the release (merged) returns its verdict with reroll null. - 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.

  ConnectorNo auth

• intel_stackA

  TunnelMind Data APIB

  Fetches up to 32KB of the domain's HTML and response headers from the edge, then fingerprints the content for known CMS platforms, JavaScript frameworks, CDN providers, and analytics tools. Detection is based on meta generator tags, script src patterns, response headers, and cookie names. Use this tool when: - You need to know what CMS (WordPress, Drupal, Shopify) a site runs. - You are assessing a domain's infrastructure before a security review. - You want to identify analytics or marketing tools a site embeds. Do NOT use this tool when: - You want HTTP headers and security posture — use `intel_http` instead. - You want tracker database classification — use `get_domain` instead. - You need robots.txt AI policy — use `intel_robots` instead. Inputs: - `domain` (query, required): Domain to fingerprint. Returns: - `cms`: detected content management system, or null. - `frameworks`: JavaScript/backend frameworks detected. - `cdn`: CDN provider detected, or null. - `analytics`: analytics and tracking tools detected. - `meta_generators`: raw meta generator tag values. Cost: - Free. No API key required. Latency: - Typical: 2-4s (HTML fetch), p99: 7s.

  ConnectorNo auth

• get_change_recordA

  Drupal Code QueryA

  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.

  ConnectorNo auth

• project_upgrade_reportA

  Drupal Code QueryA

  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.

  ConnectorNo auth

• list_projectsA

  Drupal Code QueryA

  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). 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. - Row: machine_name, title, type, installs, security, status, dev_branches (branch, installs, core_minors, era), latest_release. count: projects. next_offset is absent on the last page.

  ConnectorNo auth

• list_symbol_usersA

  Drupal Code QueryA

  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.

  ConnectorNo auth

• project_profileA

  Drupal Code QueryA

  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). - 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.

  ConnectorNo auth

• scan_composerA

  Drupal Code QueryA

  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. Sent as text with a lock path, the command lists every patch to send. target_core: 11.4 or 11.4.5. 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 extra.patches entry 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). plan.applying: the number that still apply. 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 no longer applies. - 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.

  ConnectorNo auth

• get_platformA

  webbersites-x402-data-apiA

  What is this website built with? Deterministic fingerprinting from one fetch — like the old meta generator tag, but it works even when sites strip it. Detects WordPress, Shopify, Squarespace, Wix, Webflow, GoDaddy, Drupal, Joomla, Ghost, Magento, Next.js/Nuxt/Gatsby/Astro and other frameworks, static HTML, custom PHP — with the evidence for the verdict, the raw generator tag when present, and the server/CDN stack. No AI. ($0.002 per call, paid via x402)

  ConnectorNo auth