Brainstorm: MCP-Tools Replace & Extend

AReplace: `mcp_tools` + `solcom_mcp_tools`

mcp_server komplett entfernen, mcp_tools 1.0.0-beta7 mit 28 Submodulen installieren, parallel eigenes Modul solcom_mcp_tools mit drei #[Tool]-Plugins bauen. Beide im dev-Config-Split.

# Migrations-Sequenz
ddev drush pm:uninstall \
  mcp_server_ui mcp_server_tool_bridge \
  mcp_server

ddev composer remove drupal/mcp_server
ddev composer require \
  drupal/mcp_tools:^1.0@beta

ddev drush pm:enable --yes \
  mcp_tools mcp_tools_stdio \
  mcp_tools_content mcp_tools_cache \
  mcp_tools_config mcp_tools_structure \
  # … 23 weitere Submodule …

# Eigen-Tools: #[Tool]-Plugins
namespace Drupal\solcom_mcp_tools\Plugin\tool\Tool;

#[Tool(
  id: 'list_sdc_components',
  label: 'List SDC Components',
  operation: ToolOperation::Read,
)]
class ListSdcComponents extends ToolBase { }

Pro

Con

234 Tools sofort — kein Eigen-Aufwand pro Tool

Beta-Status, kein Drupal-Security-Coverage

Composer-Konflikt gelöst, sauberer Lockfile

Maintainer-Wechsel: Acquia → CodeWheel

Eigen-Tools nutzen selbe drupal/tool-Plattform

~200 Tools im tools/list erhöhen Token-Last

Dev-Split bleibt, Stage/Prod sicher abgeschirmt

Submodul-Bump-Fragility bei Beta-Updates

Tools: 234 + 3 Composer-Konflikt: gelöst Dev-Split: ja Aufwand: mittel

BEigenbau: `mcp_server` behalten + alle Tools selbst schreiben

mcp_server bleibt. Alle benötigten Tools werden als #[Tool]-Plugins im eigenen solcom_mcp_tools-Modul geschrieben, via mcp_server_tool_bridge exponiert.

# Kein Composer-Switch
# mcp_server + mcp_server_tool_bridge
# bleiben aktiv

# Tool-Plugins selbst schreiben:
namespace Drupal\solcom_mcp_tools\Plugin\Tool;

# Benötigte Tools (Aufwandsschätzung):
# - node:create/read/update/delete → 1 Woche
# - cache:rebuild, config:status   → 2 Tage
# - views:inspect                  → 3 Tage
# - structure:field/content-type   → 1 Woche
# - theme:list/inspect             → 2 Tage
# …

# Summe: ~4-6 Wochen nur für
# mcp_tools-Parität

Pro

Con

Keine Drittpartei-Abhängigkeit für Tool-Inventar

4-6 Wochen Aufwand für Basis-Parität mit mcp_tools

Maximale Kontrolle über Tool-Semantik

Composer-Konflikt bleibt — kein mcp_tools cherry-pick

Kein Maintainer-Risiko für Core-Tools

Jedes neue Tool ist Eigenentwicklungs-Aufwand

mcp_server-SDK stabil (kein Beta-Risiko)

Kosten-Nutzen-Verhältnis ungünstig vs. mcp_tools

Tools: 0 → selbst bauen Composer-Konflikt: bleibt Dev-Split: ja Aufwand: sehr hoch

CCherry-Pick via Bridge: `mcp_server` + `mcp_tools`-Plugins

Beide Module parallel installieren, mcp_tools-Plugins via mcp_server_tool_bridge im mcp_server exponieren. Blockiert durch Composer-Konflikt.

# Theoretisch gewünschte Sequenz:
ddev composer require \
  drupal/mcp_server \
  drupal/mcp_tools \
  # ↑ Konflikt!

# mcp_tools  verlangt: mcp/sdk: ^0.2.2
# mcp_server verlangt: mcp/sdk: ^0.5.0
# → disjunkte Constraints
# → kein gemeinsamer Schnitt

# Composer-Error:
Your requirements could not be resolved
to an installable set of packages.

# Forced override:
# bricht entweder mcp_server oder
# mcp_tools zur Laufzeit — unsupported

Pro

Con

Würde beste beider Welten kombinieren

Technisch blockiert — Composer-Konflikt unauflösbar

Kein Maintainer-Wechsel bei Core-Funktionalität

SDK-Override bricht entweder Modul zur Laufzeit

Schrittweiser Umstieg möglich

Upstream-Konvergenz hat keinen Zeitplan (drupal.org)

Optionaler Pfad wenn SDK-Constraints konvergieren

Kein sicherer Hybrid-Betrieb ohne SDK-Freeze

Status: blockiert Composer-Konflikt: unlösbar (V1) Aufwand: nicht umsetzbar Zukunft: wenn SDK konvergiert